osfree.org

Kernel... a new approach ? 3.18.2005

I don't know mutch about kernels, but here are some suggestions: 1 (impossible): kernel redesign
- http://unununium.org/ 2 (difficult): compatibility layer design - http://syllable.sourceforge.net/
3 (reasonable): adaptation - http://newos.org/ Again, i'm not a developer !

Cristiano Guadagnino 3.18.2005

2Yuri: I absolutely agree with your point.
2Sergey: I am impressed by the volume of your work. Keep on!

Yuri Prokushev 3.18.2005

2Samuel Actually, we are free to use ANY kernel. But. Brief review showed RectOS as preffered
kernel. At closer view L4 is better because supports all required OS/2 memory models. ReactOS
is not. If anyone wants to start work with kernel, then L4 seems to be good choice. But, before
use kernel we need Kernel loader (OS2LDR). OS2LDR is file which loads OS2KRNL using IFS. I don't
know about such excelent and filesystem independed loading scheme. Adn I want to have it in
reimplementation. Some time ago this work was started by EDM2. And some sources (in early stage)
presented. Small part of kernel level. Who want to start?

Samuel A. Falvo II 3.19.2005

2Yuri: Why must we start out with OS2LDR though? GRUB sounds awfully similar in purpose -- it,
like OS2LDR, will actively seek and load kernels from a volume using a filesystem (for my Forth
project, I'm currently using ext2fs, but I've demonstrated it with FAT too). However, GRUB has its
own filesystem implementations embedded therein. I'm not sure how OS2LDR can use IFS if the OS
itself doesn't exist yet to provide IFS services. The only thing I can think of is that OS2LDR *IS* OS/2's
equivalent of a microkernel for x86 versions (not sure on PowerPC). Alternatively, the OS2LDR is just
configured with a starting sector number and a count of sectors, which it reads raw from the disk.
It then would be up to the OS installer to ensure a contiguous span of sectors on the volume within
whatever filesystem it is currently using. This sounds more like what's actually happening, considering
how IBMDOS.SYS and IBMBIO.SYS work on PC-DOS disks. Note that GRUB can also just read a
raw-span-of-sectors too.

Samuel A. Falvo II 3.19.2005

I am also a bit concerned, as I've written privately to Cristiano, about the restriction that all
OS/3 development take place on OS/2. This, to me, seems very self-limiting. If you truely desire
OS/3 code to be kernel back-end independent (which to me seems like a very desirable goal,
considering that more or less half of the respondants to the survey wanted ReactOS and the other
half wanted L4 as the back-end, AND the core developers strongly desire the ability to control
kernel details at a fine detail), it seems to be that the source code for the various tools ought
to be "opened up" a bit. By that, I mean that code for the OS/3 environment should be able to
be developed on any platform, including Windows or Linux if desired. However, the code should
obviously still be able to be compiled and usable on OS/2 easily. For example, according to the
project guidelines, should I decide to start playing with the idea of offering a kernel for OS/3
to use, I must do my coding under OS/2, and I interpret this as not allowing any exceptions as
well. Problem is, I don't have OS/2, and I don't intend on pirating a copy of OS/2 (I value IBM's
work far, far, far more than I value Microsoft's). I use Linux, and have used Linux non-stop since
1995. But let's ignore the kernel case, and concentrate on the CLI tools case. Currently you folks
are building a lot of the command-line environment from the tools-down (which I feel is the right
way to go to start out with, because it establishes a base-level set of libraries and APIs to be
designed next). I believe that many tools can be written rather portably though, OR, in such a
manner that the OS/2 APIs can be provided as shared libraries capable of being used on other
platforms (e.g., a VIO library that binds to ncurses, GPI to raw X11, etc.). Does any of this make
sense? The inability to properly format my text is hindering my meaning, I think. In conclusion,
I believe that following the exokernel philosophy where that which we call an "operating system"
should be bundled as a shared library that the application links against is the ideal situation. It
provides the ultimate in independence of the underlying kernel system. Of course, full functionality
won't be realized until you have your own kernel running to support the full implementation of
said libraries.

Yuri Prokushev 3.20.2005

2Samuel OS2LDR *IS* uses IFS (MicroFS part of) to load OK2KRNL. And, yes, some low-level function
(DevHelpers). And not, OS2LDR not uses any "raw reading". Please read EDM/2 articles about system
loading to learn more. According greating VIO wrapped on top of ncurses etc. No, we don't want to
have OS/2 layer on top of other OS. You can do it, but it not what we want. GPI on top of XLib is slow
thing. Main goal is to repeat OS/2 API. Yes, it can be on top of other OS. But slower and with problems
of host OS. Actually, OS/2 API must be depended only on kernel level API, not higher API (this means,
X11 can be used, but not required. I must not be forced to install and configure X11 to use PM
applications). Really, any of you can greate DOSCALLS on top of some kernel. But question is this
kernel can be actually used? Is kernel provides all things, required for OS/2 API? Not all kernels have
all required features.