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

Re: VFS ROADMAP (and vfs01.patch stage 1 available for testing)


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 16 Aug 2004 22:11:05 -0700 (PDT)

:Sounds more and more like PVM (http://www.csm.ornl.gov/pvm/pvm_home.html),
:but taken a bit further (unless PVM progressed a lot since I last looked at
:it, if so, mea culpa).
:
:-- 
:Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono

    Well, the intent isn't really to emulate a kernel within a kernel.  It's
    more a matter of design.  Either we encapsulate all the kernel data
    associated with a cluster node in a structure and then refer to it via
    that structure, sort of like how parts of a jail work now,  or we
    compile a subset of the kernel into a KLD and use kernel globals 
    as per normal (but in actuality they would be private variables 
    within the KLD).

    The biggest advantage of the KLD methodology is that there is no way
    to accidently (both from a software/compilation viewpoint and from a 
    runtime viewpoint) access information that doesn't belong to the cluster
    node.  The only hooks the cluster node would have to the real kernel
    would be to the LWKT subsystems (LWKT scheduler, slab allocator,
    certain block devices, and VM).  So, for example, the cluster node
    would have its own private user process scheduler, it's own protocol 
    stacks, it's own (virtual) network interfaces, its own filesystems,
    its own buffer cache, its own sysctl set, etc.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



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