On Tue, 9 Feb 1999, Paul Roberts wrote:
> so the real problem is that we are working in a segmented architecture with
> a compiler that doesn't really understand segments and we hide our heads in
> the sand and hope the problem goes away.
The kernel understands segments, even if the compiler doesn't. After all,
if it didn't we could only support 64KB of memory for the whole OS! What
I propose is a method for registering a program in the kernel, and
supporting access to the kernel data structure from it. Does ELKS use all
of the segment registers now? It might behoove us allow drivers to be
accessed via long jumps, and their data accessed via the ES segment. We
would need to write a couple of macros to do the DS/ES swapping before
copying data around at times, but that should be it.
Basically you'd have a call sequence like this:
user program calls read(fd, DS:addr)
kernel changes to kernel mode, saving user DS somewhere
kernel determines that fd is handled by a device driver
kernel loads ES with the devices data segment
kernel puts pointer to the device handler on the stack
kernel swaps ES and DS
kernel makes a far call to device read() handler from the stack
device driver loads data
kernel copies data into user space, using the saved DS
kernel swaps ES and DS
kernel changes to user mode, restoring the original DS
user program now has the data
Of course, this all breaks if the kernel already uses ES (although it
could still be done with a bit more work). Does this make any sense at
all?
Shane
