a proposed callout API

Matthew Dillon dillon at apollo.backplane.com
Fri Dec 1 10:39:31 PST 2006

:So,  like, why don't you work on that, instead of annoying us with your
:long lectures about how "The World Shall Be Ordered According To Me" ?

    Because, fortunately, the lives of DragonFly developers aren't governed
    by big-dick contests from people who clearly have no clue what DragonFly
    is all about.  I said from the outset that we wouldn't be taking
    shortcuts to 'compete' with other distributions, and we haven't.  The
    BGL will be turned off in the networking threads when we are good and
    ready to do it.  #1 on my priority list is achieving the major goals
    of the project and keeping the system stable while we do it.  MP is only
    part of those goals.  A big part, but still only a part.   Frankly, I
    think we have done a better job on the stability front then you guys

    My personal agenda for the January release is to finish the userland
    kernel support - basically features which allow a kernel to be built 
    as a userland application and to control independant VM spaces (its 'user'
    processes) with the help of the real kernel.  Userland kernels are linked
    against libc and the kernel APIs have to be simple enough and bullet
    proof enough for it to work as a non-root userland application.  The
    intent is to be able to do so with as little supporting overhead from
    the real kernel as possible.  This is going to be a very cool feature,
    similar in scope to usermode linux, and it is also a necessary prereq
    to reduce engineering cycle times for development of the big ticket items
    next year.

    My goals for all of next year are to make good progress on the two
    biggest ticket items in the DragonFly goal list -- SYSLINK and CCMS.
    Yes, we've finally reached the point where it is possible to actually
    start work on these items, and I'm very excited about it!  SYSLINK is
    the core protocol that will be used to communicate between hosts in
    a cluster, and CCMS is the core MESI+ cache coherency algorithm
    that will guarentee full coherency between hosts in a cluster.  A 
    staggering amount of infrastructure work on pre-existing subsystems,
    such as the buffer and namecaches, VOP API, etc, was required to get
    ready for the SYSLINK and CCMS work.  Neither will work very well if we
    have to push into the VFS every time we want to do an I/O or stat() a
    file, after all.  There is still a ton more work to do, including
    and most especially giving higher kernel layers direct access to the
    buffer cache so as to be able to bypass the VFS in the cache case (this
    is also why the namecache topology was rewritten, and is already
    the case for lookup operations).

    In anycase, I am very happy to say that we have made extremely good
    progress on all fronts.  Of all the original subsystems inherited
    from FreeBSD we are basically down to just the VM system, namecache,
    vnode(1), and packet filter APIs with regards to the MP work, and work
    is progressing on LWP style (user) threading.   Dozens of major 
    subsystems were rewritten this year, I'll have to go through the commit
    logs to get a complete list.  Things like the buffer cache, VM page
    cache, kernel user process scheduler, file descriptor handling, and
    so on and so forth.

    (note 1): The vnode ABI is a different ball of wax.  Both MP and CCMS
    have to be tightly integrated because CCMS will be used to control
    coherent access on a byte-range basis for all I/O, the intent is to
    allow the execution of multiple modifying operations on the same vnode
    to occur in parallel.  Achieving this will require a complete rewrite
    of the vnode's current lockmgr-centric API.

    That's what I'm doing.  I am also happy to say that we have some 
    wonderful developers doing a great deal of work on DragonFly, such as
    the PkgSrc integration, WiFi and other network infrastructure and drivers,
    networking, web site, documentation, bug reporting systems, and other big
    pieces that are needed to make a real platform out of DragonFly.  I
    provide enabling infrastructure to support the other work and I work on
    the major project goals.  I couldn't do it without all the help I'm

					Matthew Dillon 
					<dillon at backplane.com>

More information about the freebsd-arch mailing list