[...]
>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.
The compiler doesn't know when to use ES to dereference data; so you'd have to
wrap that with macros, so you won't get type safety.
How are you going to link all the far pointers? If you load modules
dynamically, you'd have to do this at run-time, which means patching the code.
If you do it at compile-time, you'd need a linker that understood the concept
(which we currently don't have).
Also, SS and DS must be the same; the compiler doesn't know whether a given
pointer is referring to an object on the stack or an object on the heap, so it
has to use the same address space.
I'd prefer using a module system with message-passing; the driver and the
kernel would live in seperate address spaces. The driver would get stubs for
the major kernel functions that would put together a message and send it to
the kernel. `Sending a message' would probably consist of a far call for
speed. This means you wouldn't have to do any linking; to call a function in a
driver all you have to know is the driver's segment info (SS/DS and CS) and
the entry point. For the driver to call a function in the kernel it'd have to
know the same; it's probably easier to use an interrupt for that direction.
Here's a sample stub, from the driver end:
int mmalloc(int size)
{
inbuf[0] = (WORD)size;
_call_kernel(MSG_MMALLOC, inbuf, 1, outbuf, 1)
return (int)outbuf[0];
}
_call_kernel would do, say, an int 0x81 with ax=MSG_MALLOC, bx=inbuf,
cx=outbuf, dx=0x0101.
>From the kernel's point of view things would be a bit trickier, but then, the
kernel is the right place to put tricky things.
--
+- David Given ---------------McQ-+
| Work: [EMAIL PROTECTED] | FNORD
| Play: [EMAIL PROTECTED] |
+- http://wired.st-and.ac.uk/~dg -+
