On Tue, 9 Feb 1999, David Given wrote:
> 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.
What I describes involves using ES to store the kernel's DS only for the
duration of a call into driver space. The driver need never know that ES
is being used anywhere, unless it needs to access kernel memory, in which
case it will have to use one of our handy macros. To be honest, there's
not much type safety within the kernel anyway. :P
> 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).
I do prefer loading dynamically. Yes, we'd have to do a patch - but this
should be a relatively minor change. We're only talking about a couple of
lookup tables and an API to manipulate it, after all!
> 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.
Ick! This is a big more of a sticky widget. It can be overcome by
setting up a minimal stack for the loaded driver. Again - without too
much trouble.
> 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.
To be honest, what you're describing sounds like what I'm describing. :)
I think the difference is that what you describe involves one more copy of
the data. That is:
copy from device to driver space
copy from driver space to kernel space
copy from kernel space to user space
What I propose is to do some semi-fancy register swapping to remove the
copy from driver space to kernel space. I think we'd see a marked
improvement in performance, without any additional pain, beyond a slightly
more complicated initial call to/from the driver. And when I say "marked
improvement" I'm thinking of running at nearly twice the speed (in terms
of CPU time) - well worth it.
Shane
