DragonFly kernel List (threaded) for 2003-07
Re: just curious
Matthew Dillon wrote:
For example, DragonFly will use messaging heavily but the messaging will
be a light-weight design that is, by itself, incapable of transiting a
protection boundary. The core messaging structures will not track
pointers or message sizes, for example. Instead what we will do is
support the transiting of protection boundaries by creating port
abstractions which do the appropriate translation into and out of forms
that *can* cross a protection boundary.
What a coincidence. I was just involved in a discussion on comp.arch
where I proposed a "proxy" mechanism to avoid the overhead of "heavy"
microkernels... I was thinking in terms of how you would map something
like Amiga message ports into something that could cross protection
boundaries by having a thread that just recieved messages and marshalled
them into handles and encapsulated data before tossing them through a
callgate to the real kernel-mode handler.
Your mechanism should be better because it gets rid of that extra thread
without, so far as I can see, making the message passing more expensive
within a protection boundary.
One thing that might be harder: I was looking to reduce the effect of
the boundary crossing by taking a series of independent system calls and
queuing them up and tossing them over the boundary together. That way
you would be able to, for example, queue writes to multiple files,
devices, or sockets in a single system call.
But now that I think of it you could implement a Send() function that
did the same thing.