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

Re: Flames ahoy

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 8 Apr 2004 18:43:14 -0700 (PDT)

:I really don't want this to turn bad, so please keep 
:emotions out of it. I am just curious as to why you(Matt) 
:chose to base DragonFly on FreeBSD 4.x and not NetBSD? Those 
:NetBSD guys seem to be keeping things sane..

    I'm most familiar with the FreeBSD kernel, having used it from the
    mid 90's on and worked on it throughout.  FreeBSD-4.x was best positioned
    for me to start DragonFly with... it had basic SMP features but did not
    have the mess (in my view) that FreeBSD-5 has become, and we were
    able to begin with the advantage of knowing all the things that were
    done wrong between FreeBSD-4 and 5 and thus were able to avoid areas
    that I considered to be huge design mistakes in 5.  In particular,
    the FreeBSD-5 mutex model and its continuance of a stack-context-centric
    kernel multi processing model (something which all the BSDs share but
    which DragonFly does not, any more).

    I also tend to prefer the FreeBSD mach-based VM system (i.e. the
    VM Object model) over both earlier BSD VM systems and contemporary
    systems like UVM.

    Also, there isn't much of a point starting with an operating system
    focused on multi-platform support when some of the basic goals I wanted
    to accomplish were going to require the rewriting of most of the
    core assembly (e.g. in order to implement LWKT properly), and hence
    we would have had to throw away all of that support anyway.  Even in
    DFly I've had to throw away alpha and PC98 support.  That may seem a bit
    backwards, but the fact of the matter is that the more architectures you
    support, the more your core assembly APIs get locked in and become

					Matthew Dillon 

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