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

Re: VKernel progress update - 9 Jan 2006

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 11 Jan 2007 10:59:39 -0800 (PST)

:On Wed, January 10, 2007 8:44 pm, Gergo Szakal wrote:
:> Uhm, from the user's point of view: how about an rc.conf-like file
:> (rc.vkernel) to store this values?
:Perhaps as a switch when running the kernel, so that alternate files can
:be specified?  Of course, it's easy for me to suggest what I don't know
:how to implement...

    I don't think we'll have an /etc/vkernel.conf for this release, but
    it is absolutely needed for any production use.

    I can imagine a system which uses several vkernels in production
    (possibly even 'many' vkernels).  Clearly some sort of config file
    is needed to start up the vkernels and to manage and maintain their
    operation (or at least detect when something goes wrong and complain
    about it).

    Even more importantly, the biggest resource used by a vkernel that
    cannot be automatically allocated is its ROOT disk.  We have several
    choices here, including NFS boot over the TAP/NKE.  To make it really
    useful, though, we need a disk managment layer.  Again, not this
    release, but the writing is on the wall.  We need one.

    Post-release (end of january) I will be shifting gears over to the
    SYSLINK and CCMS subsystems (clustering and cache coherency).  I
    want other developers to take up the ball on the virtual kernel and
    flesh it out, now that the hard part is done.   I did the virtual kernel
    core for entirely selfish reasons :-) it makes kernel development a
    whole lot easier.  Clearly there are major production uses for virtual
    kernels as well and I need the rest of our development community to
    develop those uses!

    Linux has something similar (UML), but no BSD system has this feature.
    All the BSDs rely on third party hardware virtualization (vmware, xen,
    qemu, etc).

    The linux code is fairly opaque.  It is almost universally without any
    code comments so I am not sure whether they are using a real page table
    (requiring UML to run as root), or whether they are using a virtualized
    page table like we are (which allows us to run without needing root
    creds).  Inquiring minds want to know!

					Matthew Dillon 

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