DragonFly kernel List (threaded) for 2003-07
Re: just curious
Matthew Dillon wrote:
:I think microkernels have moved on since mach, active projects
:like L4-descendents from Karlsruhe university (http://l4ka.org/)
:and fiasco from Dresden (http://os.inf.tu-dresden.de/L4/) appear
:to function quite well. I played around with those some weeks ago
:and was quite impressed (after being exposed to mach many years
:What lacks in most u-kernel implementations is some meaningful
:userland "kernel." Moving stuff from the kernel to some kernel-ish
:process (for lack of a better word) seems useful to me. If I
:understand you correctly you're aiming at a best of both worlds
:approach: 'simple' kernel and delegating complex issues to userland?
My primary interest in userland kernel extensions, like a VFS layer,
is to be able to implement complex features targeted to specific tasks
(for example, a VFS environment to verify that a package depends on
only what we think it depends on). I do not think there is much to be
gained by moving major pieces of the kernel into userland. The
DragonFly design would allow that sort of work to be done, but it
isn't a Goal. I think that even after all the work is done
DragonFly will still qualify as a monolithic kernel design. Or perhaps
someone will come up with a new name.
I think some profit may be gained from moving stuff from the kernel to
userland. Some kernel functionality might be delegated to userland
libraries/serverprocesses in conjunction with an efficient IPC system.
These "userland libraries/serverprocesses" (let's call them ULSP for
now) would be part proxy, part implementation of some feature.
Defining some notion of processgroups (e.g. that may share parts of each
others space, or are simply allowed to communicate only within their
group) may lead to more flexibility. Such a group might be quite
independent from the rest of the system (a bit like jail(8)), only
communicating with the kernel when it's necessary.
It may also enable using different API's for different applications
(say, some group may have its networking API denied to them, forcing
them to go through a ULSP for their group. This, in practice, would be
delivering networking related messages to a ULSP instead of the kernel.)
As a result applications can be made less aware of the underlying
system. A message to 'networking' is handled by the ULSP, that may be
instructed to do IPv6 on one node or IPsec on another.
Security wise this may also have some implications as it enables you to
isolate processes or (rather) easily put some extra layer (firewall,
logging, sanity check, postprocessing, compression etc.) around it.
:Another question, how far does the messaging go, i.e. would it
:extend to something like network/grid computing?
The core messaging, no. With appropriate translation agents as the
mp_SendMsg port functions, yes. And that would likely be how we would
implement such messaging. At some point down the line when the caching
model is working internally we *will* have to extend it across the
network, and at that point we might come up with an API that deals
with the issues such an extension entails (like timeouts, failures,
OK, just asking because it would be nice to have something that
naturally scales over multiple nodes (be it costly in terms of latency.)