DragonFly kernel List (threaded) for 2003-07
Re: just curious
> Well, the traditional definition of a microkernel has a lot of negative
> connotations, which I blame on Mach. DragonFly is definitely not going
> to be a traditional microkernel but it will retain many of the better
> qualities of a microkernel design.
Mach is big. L4 is neat and small.... another interest.
> 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.
So ports are opaque handles representing permission granted to write into another
process's address space? Does it require a matching receive on the receive end?
If so... is the data buffered in the kernel or is it merely kept on the sender side to be
copied into the receiver's address space later.
I suppose you could, of course, play some games with shadowing pages as copy-on-write
in the VM across process boundaries?
I am mostly thinking out loud but this idea has me quite intrigued.