"Kevin P. Lawton" <[EMAIL PROTECTED]> wrote:
[ Sorry for not participating in the discussions lately, but I was
occupied otherwise :-/ Now that my thesis is finished, I should
be able to find more time to work again on FreeMWare ... ]
> Ramon wrote a very slim kernel call nullkernel for just this purpose.
> The idea is for it to use very few features so we would not have
> to virtualize much to start with. It's available by FTP. It doesn't
> even use paging. There are 2 variants. One doesn't use interrupts
> for scheduling (thus doesn't even need IO to program the PITs).
> An excellent first kernel to work with. We can add features to it as
> we go.
Yes, I think the next thing to do is to try and get the nullkernel
running.
> For nullkernel, the things we need to look for are:
>
> - user code uses system call (soft interrupt)
> - system code uses transitions to user code
> - writes go to VGA text framebuffer memory (0xB8000) for some
> output to screen.
> - LTR, IRET, MOV CS,xyz, LIDT, PUSHFL/POPFL, LGDT instructions
> - control transfers
I've been thinking about the next small steps: Unless you are
already working on it, I'd been planning to clean up the monitor's
interrupt/exception handling a bit and add some kind of framework
to process exceptions (most importantly page fault and GPF) for
monitor purposes.
This should then allow to implement virtualization of the GDT/LDT/IDT
by mapping it as no-access and trapping faults when accessing it.
This would seem to be biggest obstacle to get the nullkernel running
(as it fortunately doesn't use paging ...).
In any case, we probably won't get everything perfect on the first
try anyway; for now I think it is important to try out a few
techniques and see where the problems turn out to be hiding ;-)
Bye,
Ulrich
