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

Re: Development stalling?

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 23 Apr 2006 00:09:15 -0700 (PDT)

    Well, I would say that nothing has been abandoned, but these items need
    developer hands for progress to take place and I am only one person.
    There are a lot of people working the edges (and this is very necessary
    in order for DragonFly to remain viable), but only a handful of people
    doing big ticket items.  Users have different needs and, unfortunately,
    it is not possible to make all of them priority #1.

    My focus is squarely on the critical path, which I outlined at the
    beginning of the year:  A cache coherency model that works well 
    enough to be able to migrate execution contexts between machines,
    a userland VFS interface (primarily so ZFS can be ported in userland
    == more developer hands available to help out), and other issues related
    to supporting clustering.

    Laying the groundwork for this is itself a huge task.  It's pretty much
    all I have been doing for the last two years.  For example, userland
    VFS is impractical without a VFS API that is capable of breaking UIO's
    up into buffer-sized segments, or without direct buffer cache access
    above the VFS layer for it to be efficient.  To do cache coherency right
    we need a ranged locking layer (actually several layers), which means
    that the entire I/O subsystem had to be converted to a byte-oriented
    API from a block oriented API.  In fact, we have to get rid of global
    vnode locks entirely, which will not be easy.  Its a huge list.

    AMD64 is desireable, as is more SMP work, and I'd be quite happy if
    other developers did some work in those areas.  Not to mention keeping
    device drivers up to date.  But I could spend my entire life doing 
    nothing but device drivers and have nothing truely innovative or 
    interesting to show for it at the end of that road.  So despite its
    importance it would be a very bad move for me to drop everything and 
    focus on driver maintainance.  I have to prioritize my own work and right
    now that priority is on cache coherency and cluster-related code.
    The edge work keeps us within shouting distance of all our goals, but
    the large scale pushes are necessarily going to be far more narrowly

    If you want to help out then choose something near and dear to your heart
    and start working on it.  My only caution is that large scale endevours
    must be done in committable bite-sized chunks.  Trying to do something
    like AMD64 in one big patch, for example, would only result in an
    undebuggable mess.


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