Slashdot Mirror

← Back to Stories (view on slashdot.org)

DragonFly BSD Announced

Posted by timothy on from the skimming-and-darting dept.

JoshRendlesham writes "Matt Dillon announced today on the freebsd-hackers mailing list the creation of the DragonFly BSD project. It seeks to build on the work of FreeBSD 4.x, including a rewrite of the packaging and distribution system, among other goals."

4 of 460 comments (clear)

  1. Re:pkg could be a lot better by iiioxx · · Score: 5, Informative

    I gotta chime in here:
    It really pisses me off that FreeBSD does not let you (by default)
    cd /usr/ports
    make update
    I dunno, I think cvsup and portupgrade do the deed quite nicely.

    # cd /usr/ports/net/cvsup-without-gui
    # make install && make clean
    # cd /usr/ports/sysutils/portupgrade
    # make install && make clean

    # mkdir -p /usr/local/etc/cvsup/sup
    # cp /usr/share/examples/cvsup/refuse /usr/local/etc/cvsup/sup

    ... tweak /etc/make.conf ...

    CFLAGS= -O -pipe
    COPTFLAGS= -O -pipe
    NOPROFILE= true
    USA_RESIDENT= YES (if you are)

    ... create /usr/local/etc/cvsup/sup/supfile ...

    *default host=cvsup2.freebsd.org
    *default base=/usr/local/etc/cvsup
    *default release=cvs tag=RELENG_5_1 (or your version)
    *default delete use-rel-suffix
    *default compress
    src-all
    ports-all tag=.
    doc-all tag=.
    ... then update your src and ports ...
    # /usr/local/bin/cvsup -g -L 2 /usr/local/etc/cvsup/sup/supfile
    # /usr/local/bin/portupgrade -ra

     Granted, you have to build a supfile, and tweak your /etc/make.conf a little first... But those are minor things, and in the case of cvsup, there are loads of good examples provided in /usr/share/examples/cvsup.

  2. Re:Why 4.x? by m.dillon · · Score: 5, Informative
    That is the crux of the issue. The problem is that while a great deal of work has gone into FreeBSD-5.x, it is all based on a fine-grained mutex locking MP model that is simply not compatible with the methodologies being implemented for DragonFly. 4.x isn't actually 'old', a good deal of non-MP related work has been merged from 5.x into 4.x. We miss out on a few big things, like UFS2, snapshots, and the security infrastructure in 5.x, but 6 months down the road when we have our new infrastructure in place reimplementing those items will be a trivial exercise. Also, 4.x is a far more stable base to work from then 5.x.

    Insofar as performance goes, a higher version number does not mean higher performance. 4.x is a lot faster then 5.x for many types of tasks. DragonFly will be able to implement critical subsystems in MP, like the TCP stack, using an essentially mutexless design, which ultimately means that DragonFly will theoretically be able to perform better then 5.x in an MP environment once both are able to completely remove the MP lock. But that is down the road quite a bit and a lot can happen between then and now.

  3. Re:New Packaging System by dododge · · Score: 5, Informative
    Are they talking about replacing the ports system?

    It's more than just replacing ports with portage, or apt-get, or some other userspace packaging system.

    What they're talking about doing is having kernel support for packaging. Multiple versions of the same library could be installed with the same filename simultaneously. An application would see the correct versions of the things it needs, and it would see only the things it needs, despite what else might be installed. This is to allow for piecemeal/partial upgrades among other things.

    To which I say: HALLELUJAH BROTHER!

    This is exactly what I've been wanting to graft onto Linux for some time now; my latest thinking is that it could be done with a userspace filesystem (to make files visible/invisible), extended attributes (to associate the visibility contexts with application binaries), and a bit of extra process state. If the DragonFlyBSD folks make it work, it'll be intrestesting to see how this behaves from an administrative point of view.

    In any case, this is not just a userspace change. This involves the kernel itself.

  4. Re:Messaging layer by m.dillon · · Score: 5, Informative
    There are many Amiga-like concepts incorporated into the model, and plenty of new stuff as well. The Amiga had a highly optimal messaging system oweing to the fact that it ran on such a slow cpu making every cycle golden. Two features have been taken from the Amgia I/O model. First, the idea that the target can choose to perform an operation synchronously or asynchronously entirely independant of the type of operation the client has requested. In the Amiga model the client passes a hint which the target may choose to act on or choose to ignore and so do we.

    Another feature taken from the Amiga I/O model (for those who ever looked at the actual assembly code) is the ability to short-cut queueing operations. For example, if the target is able to execute a message synchronously regardless of what the client requested, the target can execute the message in the client's context and return a synchronous result code without even bothering to queue the message (I/O request in Amiga terminology). Likewise, if the client wants to run an operation synchronously and the target decides to run it asynchronously the target doesn't have to queue the message back to the client's reply port when it is through, it simply wakes the (blocked) client up.

    To make messaging truely efficient the 'optimal' case must have the lowest possible overhead. The Amiga model serves this requirement very nicely, making optimally handled messages take no more overhead then a subroutine call would take. This is extremely important in an MP design because queueing operations often require some sort of lock and being able to avoid a queueing operation in the optimal case is simply *HUGE*.

    Consider the optimal syscall path given the above. If a syscall can run without blocking your syscall 'message' winds up costing no more then a traditional syscall would. After all, there is no point asynchronizing a syscall that can run without blocking, you only have one cpu for any given userland thread anyway so you can't make things faster by switching out to handle something else and then back again. Yet in a traditional asynchronizing model like AIO, a great deal of effort and overhead is taken before you even know whether the I/O operation would block or not, making AIO expensive no matter how you cut it. The same goes with a select() based operation. And in a KSE style operation the expense occurs in having to maintain multiple kernel threads for system calls which are in-progress, instead of much smaller message structuers for system calls which are in-progress. The above Amiga-like features make it possible to encapsulate *ALL* system calls in messages, request asynchronous completion, yet still deal with synchronous completion in a manner which does not introduce a performance penalty.