osfree.org

Alex Bervoets 3.31.2005

2SamuelIOPL: I can imagine that certain existing programs use the IOPL feature for strict I/O
timing purposes. So running IOPL code in ring 3, which results in a GPF at each IN/OUT instruction,
and then emulating this in the kernel will certainly introduce a serious performance degradation,
which could break compatibility with these apps.

Another issue: IOPL code is 16 bit code, so a new application loader has to load an application with
mixed 16 and 32 bit segments correctly and has to replace the call gates with some sort of thunking
mechanism.

Concerning the CLI instruction issue: I assume that certain applications disable interrupts in IOPL mode
to prevent the kernel from accessing the same I/O ports, should the code become preemted by an interrupt.
Now a quick and dirty solution could be to only disable the IRQ (mask out in PIC) which corresponds to the
I/O port being accessed. The kernel could maintain a list of I/O port ranges and corresponding IRQ's. Also,
there could be an extra CLI/STI GPF flag in the process information block. A GPF on a CLI instruction will
set this flag. Now if there's an I/O GPF and this flag is set, then the corresponding IRQ should be disabled.
However, I see already an issue here: what in the case of code like "PUSHF CLI ... POPF" (no STI) : popf should
enable the interrupts again but there's no GPF to clear the flag. The question is of course "Are we going to
keep on supporting this old, unsafe and potentially dangerous stuff ?".

2SamuelQEMU: I've done some googling and apparently there're also other OS-es having problems with QEMU's
ide emulation. I've read several suggestions: one was to use the latest CVS version, another one was to use the
switch -isa when launching qemu. If you want to see the ide detection process in OS/2, then add the 2 switches
/V /W to the line basedev=ibm1s506.add in config.sys. If you want to disable bus mastering in OS/2, then add
the 2 switches /a:0 /!bm to this line in config.sys.

2All: Can we use Program Commander/2 as a WPS replacement ? PC/2 is freeware with the source code included.

Cristiano Guadagnino 3.31.2005

2Alex: You must be kidding!! WPS is the single most important piece of OS/2 that we want to
keep and enhance, AND is (still) the most advanced UI ever conceived and realized in an OS. I
don't know how much you're familiar with OS/2 and the WPS, but in my view I'd prefer to give up
the entire project than to give up the WPS. Sure, the WPS is not open source, but if we can get to
the point where we attract sufficient interest from the remaining OS/2 developers to get Ulrich
Moeller to join the project, we're done. I believe he has almost all the knowledge we need to
recreate the WPS (and even make it better).

Alex Bervoets 4.1.2005

2Cristiano: Well, maybe I expressed myself incorrectly but I don't meant PC/2 to be the final WPS of
course. It only appears to me that PC/2 is no longer actively being maintained so we can take its
source code, as opposed to XWorkplace.

Samuel A. Falvo II 4.1.2005

2YuriBoot up: I'll do some more research in this area. I need to very closely study the FREELDR sources
to figure out how things currently work (in particular to learn how to discover the micro-FSD and perhaps
even to learn how to use the mini-FSD), since the articles that I read still don't give me enough information
for outright implementation. What I'll do then is write up a quick proposal for how the new loader system
based on L4Ka::Pistachio (since that is what I'm most familiar with and has the most up to date API) is
expected to work. I don't have an ETA on this unfortunately, as this is the last day of my "weekend" -- back
to work for me for the next four days.

Cristiano Guadagnino 4.1.2005

2Alex: agreed I think it would be better to ask the author BTW, even if the software has not been
updated for years, now. I don't know if he is still reachable.

Samuel A. Falvo II 4.1.2005

2Yuri: I've done some research and the OS/2 boot sequence is quite fascinating. I'm convinced
that I can arrive at something comparable. We unfortunately will still need an OS3BOOT mini-FSD
for this to work, however. The reason is, once L4 takes over, everything will be 32-bit protected mode.
Hence, in order for OS3LDR (if you'll pardon the use of the term, and which is built on top of L4) to
load the remainder of the system, it will need not only a 32-bit clean mini-FSD to work with, but also
a miniature DASD driver too. OS3BOOT seems the most logical place to put this kind of thing. (The
disadvantage to this is that the SYS helper functionality must be aware of the kind of device the
installation is being put on, so that it can use the appropriate driver code. IDE and floppy code can
be relatively easy to support. But I'm not sure about USB, if for example, we want to support booting
off of USB storage.) If you would like, I can attempt to work up a quick and dirty prototype to
demonstrate the concept, along with a textual explanation of how it all works. I'll be using ELF
since that is what I have most experience with and allows me to use the tools that I currently have (I
still haven't gotten around to getting OS/2 reinstalled just yet). But again, as a prototype, it should be
good enough for us to test and play around with. Of course, that means I should probably implement a
few tools to implement/support the LEAN filesystem, since it's markedly different from both FAT and
HPFS -- definitely a good test base for this.

Yuri Prokushev 4.2.2005

2Cristiano: Exactly. I mean out private list. I need remeber how to access them and
I'll add Samuel to list.

Yuri Prokushev 4.2.2005

2Samuel Prototype is good place to start, IMHO. And ELF is also ok at this point. Also you can
try contact Pavel Stemenko (NTFS.IFS/BootJFS developer) and ask him about some point of
boot sequence. May be he has information for you.

Yuri Prokushev 4.2.2005

2Alex/Cristiano: According WPS. Before WPS we need to have SOM reimplementation. Personally I
like to work on SOM compiler reimplementation. We have good documentation about SC internals
and I successfully created draft of emitter to start reimplementation of required classes step-by-step.
According temporary WPS replacement. I consider we need talk about it later, after GDI/PM
reimplementation.

Samuel A. Falvo II 4.2.2005

Well, I think I've written up a decent, if preliminary, plan of attack for the boot loading prototype.
Please see it at http://www.falvotech.com/projects/os3.php and let me know what you think. I'm
starting to see the immensity of the scope of even this part of the boot process; personally, I think
this makes writing the actual kernel itself pale in comparison. Getting L4Ka::Pistachio to work
without Grub won't be easy, I predict.