Re: C style documentation

>Would it be possible to have a message handled by the kernel to go
>back to real mode and execute some code there?

It is interesting to note that, unlike Plan 9, the microkernel currently
does not respond to any messages. It passes them on to a server, but
the kernel does not contain any code which *acts* as a server. I was
rather surprised when I finished writing the message handling code at
how un-natural it would be to bolt kernel handling onto the messaging
code. I decided to run with my first impression. So far, it's done OK.

>This way we could write a server for real-mode hard disk access and
>use all the hardware that we have while the drivers get developed?

There would be real challenges. ALL memory has been taken over by
VSTa, so you have no real guarantees that you can assemble a workable
environment in which to run a card's BIOS. Lots of problems with
interrupts and the like. It's something of a pain to wander back
and forth from protected mode to real mode, too.

When I was first writing VSTa, I pondered long and hard on how to
get myself bootstrapped. I decided that the best way to keep access
to all my hardware was to cross-compile from another OS. I chose
DOS because it's easy to take the machine over once you've generated
an image. The djgpp compiler is full GCC 2.X, there are lots of very
reasonable editors for DOS, and a boot into VSTa takes ~10 seconds.
You don't need a disk driver to boot VSTa; comment out the dos filesystem,
the disk drivers, and init. Add back in a -DSTAND version of testsh,
and you can talk to the tmp filesystem, namer, etc. without any hard
disk storage at all! As you write a disk driver you can boot up VSTa
and talk to your driver via testsh.

This is how I brought up VSTa, and it works pretty well. As you saw
from my status message last night it's still pretty much how I work,
except that I now have the luxury of using a DOS file as my "disk" for
testing instead of having to use a real disk.

When we have dmake and RCS ported it should be possible to entirely
self-host the development process. For the foreseeable future I want
to continue to support DOS cross-compilations for situations exactly
like yours.

                                                Regards,
                                                Andy
Received on Tue Aug 31 22:30:48 1993