just curious

[Ebo]

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 at 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.