osfree.org

Samuel A. Falvo II 3.23.2005

Oops -- when I said OS2LDR was a microkernel, I meant to say nanokernel or hardware abstraction
layer. But I agree with the article thus quoted: with each succeeding revision of OS/2, OS2LDR has
gotten increasing amounts of functionality that raises the semantic level of the *-kernel. My question
now is, what are the goals of FREELDR for x86? Is it to be a real microkernel, or just a nanokernel?

Yuri Prokushev 3.25.2005

2Cristiano: Yes, unfortunately, in Russian. Most probably we'll translate it step by step. Of cource,
any help welcomed According mailing list. I agree, but we actually need to start working with kernel
NOW Problem is coding starter (as always ).

2Samuel: Ok, but GRUB is monolitic application. If you want to add support of another file=system,
boot method, etc. then you need to change code. OS2LDR doesn't need it. OS2LDR is excelent solution
of existing problem. And I prefer to continue usage of such solution. According 16-bitcode. At hte
present time switch to 32-bit mode done by OS2KRNL. We can do such switching on OS2LDR level.
No problem (only qestion is IFSes. We need to be sure IFS can work in such manner).

According OS2LDR goal on x86. Don't know

According non-LX format. Most-preffered was is support to any format via something like plugins or
hooks.

According "languages war" Actually, I prefer Component Pascal, but only Java version of it exists
on Os/2.

According SOM/IDL. BTW, IBM's IDL compiler (SOM Compiler) is one of the best IDL compiler
implementation I know. Unfortunately, part we need to extend (IDL parser) is not extensible

2Alex According ReactOS kernel fork. Don't think it's good idea. Most preffered thing is use
Dirver Virtualization technology of L4 kernel.

According GRUB. Don't think we need use GRUB as is. OS2LDR logic has some significan advantages.
And we need them. Yes, we must reuse existent code, but not "just get it and compile it". As example,
look at LOT of buildings/rebuildings of various libs, like zlib, pnglib, etc. Instead of one correct
implementation we have LOT of DIFFERENT ports of same things. No, we need not.

According alpha. Yes, it possible to have pre-pre-alpha of core text-mode api of OS/2. I mean
stdin/stdout/memory managment & some FS functions. And nothing more. If it will be dne in this year,
then next year we can start work on VIO subsystem. But first we need to boot kernel and start mimishell.

2All Really first step I prefer to see is OS2LDR reimplementation with L4 kernel and some functions
on top: DosOpen, DosRead, DosWrite & DosClose using IFS. This means we need miminal memory
managment functions set (to allocate IFS code in memory) and executable format parser (LX in our
case) also. This is MINIMAL task to start. Later we need to create stdio functions (no VIO yet).
After this we can start to implement functions required for our build tools. MHO.

Samuel A. Falvo II 3.25.2005

2Yuri: I don't know if we need memory management functionality at that low a level of the
loading process. We can extend the boot loader to support installable executable formats too
using the same method it uses to support IFS. But doing so means that we need something like
OS2FMT or some such to be loaded in as well. Also, OS2LDR and OS2BOOT appear (so far as I
can tell) to load at specific fixed addresses in the memory map. I'm not sure if this is determined
by the origin set in the LX header or if it's pre-wired into the boot manager code. As I'm going to
be at work for the next four days, working 10 hour shifts, don't expect much to get researched
in that time. I think the next step for me is to examine and do a code walk-through of FREELDR.

Samuel A. Falvo II 3.25.2005

2Yuri: "At hte present time switch to 32-bit mode done by OS2KRNL." According to the
sites I posted earlier, this is not true. OS2LDR is what actually engages protected mode,
AND, even hangs around for the lifetime of the system providing some low-level services
to OS2KRNL itself (e.g., it behaves as a kind of hardware abstraction layer).

Yuri Prokushev 3.26.2005

2Samuel Hm... I agree, we need not memory manager yet at that level. As result of my thinking,
I propose following logic:

1. OS2LDR must switch to protected mode
2. Using microFSD we can load
   1. MiniFSD (which represented as DLL library)
   2. L4 microkernel
   3. load OS/3 kernel process.
3. After correspnd allocation of required code, execute L4 and OS/2 kernel process.

We can skip loading of MiniGSD at all and use MicroFSD (which entry points passed to OS2LDR)
and implement MicroFSD loading in OS/3 kernel process.

According type of OS2LDR file.
OS2LDR is plain binary like COM, but with zero offset (not 100h).

According OS2FMT. We need to create same thing as for IFS and let them called like
fomatname.fmt. We need to create corresponding interface first and document them
before coding As result, we must support in OS2LDR loading of LX executable format
(in minimal level).

Samuel A. Falvo II 3.27.2005

Hmm...I'm not sure about this process, as I sense it conflicts with OS/3's stated goals for
compatibility. L4 requires two processes to be installed and running by default: Sigma0
(which we can just use the default one, I *think*. The sigma0 process is responsible for
the *initial* dissemination of system memory to the root process, and from there, it can
be disseminated as needed to other processes), and the root task itself (which in our case
would be OS2KRNL). As such, the OS2LDR would need to look for the miniFSD (which runs
in 16-bit code since it'll use BIOS to actually read from the disk interface, presumably),
L4 itself, sigma0, and then OS2KRNL. That's four files instead of two. Launching L4 will
implicitly launch sigma0 and OS2KRNL. In other words, I can't see any other way around
having L4 being part of the OS2KRNL boot process (versus the OS2LDR process). If all you're
interested in is what happens /after/ the boot process, then this will work. But based on prior
evidence, you are particularly interested in boot-time compatibility as well. Therefore, I'm
thinking that we might be taking things a bit more complicated than they need to be.

My proposal is to use the existing OS/2 boot process, basing it on the already available (and
apparently working?) FREELDR. The trick is to find a way to fit three programs (L4, sigma0
process, and the real OS/3 kernel) all into OS2KRNL in such a way that, when run, it will
initialize L4's Kernel Information Page, then invoke the L4 entry point.

Samuel A. Falvo II 3.27.2005

Also, doesn't OS/2 have code which is sometimes required to run at ring 2 and/or ring 1? If so, I believe
that will break compatibility with L4 as well, as L4 is a strict ring 3/ring 0 kernel environment. I'm curious
to learn this because OS/2-for-PPC had to encounter this process (PowerPCs only have kernel-mode and
user-mode). How did OS/2-PPC reconcile this issue with its x86 cousin? I'm sure that there had to be some
amount of source code incompatibility between them (unlike Windows NT/2K, where the same source
builds on multiple CPU architectures). Anyone have any info on this? This could be useful information to
have this early in the game, so that we can design the architecture accordingly.

Alex Bervoets 3.28.2005

Ring 1 isn't used, ring 2 is reserved for 16 bit physical device drivers, network services, IOPL calls.
There's an excellent article at http://www.sjoerd-visser.demon.nl/os2/multitask.html "Privilege levels"
(unfortunately in dutch). See also OS/2 Warp (PowerPC Edition) IBM RedBook SG24-4630-00 (can be
downloaded from http://happyos2.darktech.org/Gfd.Inf.Os2.Html , file SG244630.ZIP).

OS/2 warp Power PC edition 3.28.2005

Get it directly from IBM website : http://www.redbooks.ibm.com/pubs/pdfs/r ... 244630.pdf

Samuel A. Falvo II 3.28.2005

OK, so the ring levels are only for legacy applications and driver compatibility then. That's very
nice to know! I'll have to do some reading after work tonight.