Annoucning DragonFly BSD!

Matthew Dillon dillon at
Sat Jul 19 11:15:34 PDT 2003

:OK, you want a divergent kernel, EG src/sys/ ,  fair enough.
:  - Are there any benefits to the BSD community in having
:    a 4th BSD bin/ sbin/ usr.bin/ usr.sbin/ ?
:    Can you not share & co-operate with toolset maintainers of NetBSD
:    or OpenBSD, even if you can't work with some FreeBSD CVS people ?      

    I don't think these particular subhiearchies are that big a deal.
    Except for libc and libc_r, most of the above will wind up being
    almost identical to their 4.x counterparts.  You know the old saying...
    if it aint broke...

    One big part of the goal set will be the creation of a middle 'emulation'
    layer which is managed by the kernel but runs in userland, which will
    take over all primary system call entry points (in userland) and convert
    them to syscall messages that the kernel understands.  4.x, 5.x, SysV,
    Linux, and other compatibility sets will be moved out of the kernel and
    into this middle layer.  Even the 'native' syscall set will run through
    an emulation layer (though being aware of it the native sets will call
    the emulation layer directly rather then bounce through the kernel).

    The advantage of this methodology is that we will be able to keep the
    kernel clean.  For example, we would be able to modify how certain syscall
    messages work and simply by fixing the backend of the appropriate 
    emulation layers we can maintain binary compatibility with any past
    userland.  The emulation layer would be fully versioned so older 
    userland programs use emulation layers targeted to older APIs, and newer
    userland programs use emulation layers targeted to newer APIs.

    So there would no longer be five different versions of stat() in the
    kernel, for example.  There might be five different versions of the
    '4.x emulation layer', but there would be only *ONE* stat in the kernel.

:  - Do you intend your own ports/ collection too ? (or  Free, Net or Open ?) 
:Julian Stacey       Freelance Systems Engineer, Unix & Net Consultant, Munich.

    A Packaging system is a very important piece of any distribution.  Our
    goal will be to create a packaging system that, via VFS 'environments',
    causes any particular package to see only the dependancies that it
    depends on, and the proper version of said dependancies as well.  Multiple
    versions of third party apps that normally conflict with each other could
    be installed simultaniously.  The packaging-system-controlled VFS
    environment would also hide everything a package does not depend on,
    like other libraries in the system, in order to guarentee that the
    dependancies listed in the packaging system are in fact what the
    application depends on.  There's no point in having a packaging system
    that can't detect broken and incorrect dependancies or we wind up with
    the same mess that we have with ports.

    To make this work the VFS environment would have to be able to run as
    a userland process.  Otherwise we would never be able to throw in the
    type of flexibility and sophistication required to make it do what we
    want it to do, and the kernel interfacing would have to be quite robust.
    I want to make these environments so ubiquitous that they are simply
    taken for granted.  Begin userland VFSs with the capability of
    overlaying the entire filesystem space, these environments would be
    extremely powerful.

    It might be possible to build this new packaging system on top of the
    existing ports infrastructure.  It will be several months (possibly
    6-12 months) before the kernelland is sufficienctly progressed to be
    able to imlpement the userland VFS concept so we have a lot of time to
    think about how to do it.

					    Matthew Dillon 
					    <dillon at>

More information about the freebsd-current mailing list