DragonFly kernel List (threaded) for 2004-04
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: Flames ahoy
: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
unchangeable.
-Matt
Matthew Dillon
<dillon@xxxxxxxxxxxxx>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]