DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: just curious


From: Ebo <dragonfly@xxxxxxxxxxxxxxxx>
Date: Sat, 19 Jul 2003 18:33:01 +0200



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
:ago :-)
:
: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?
:(millikernel? ;)
:

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?
:
:
:E.

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,
etc).


-Matt
Matthew Dillon <dillon@xxxxxxxxxxxxx>



OK, just asking because it would be nice to have something that naturally scales over multiple nodes (be it costly in terms of latency.)



E.






[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]