Date: Wed, 7 Jan 2004 15:17:36 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: jsd@jdyson.com Cc: Munden Randall J <Randall.Munden@umb.com> Subject: Re: Where is FreeBSD going? Message-ID: <200401072317.i07NHaM9065411@apollo.backplane.com> References: <200401062000.i06K0hSI012184@dyson.jdyson.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:It is INTERESTING to comment on someone whose viewpoint doesn't extend
:beyond the VM system, because out of Greenman, me and even Matt Dillon,
:(and the extremely respected alc), I don't know of any people
:with a myopic VM viewpoint. An example of that might be Matts ability
:and succes dealing with the VERY IMPORTANT NFS issues, or perhaps my implementation
:of the vfs_bio merged cache, minimal-copy pipe code, kernel memory management
:improvements (which aren't really VM per se), early playing with the ATA
:driver, SIGNIFICANT filesystem work (e.g. the vastly improved LFS didnt'
:get installed because of softupdates making it redundant), careful rework of
:certain portions of low level code, and it is definitely ludicrous
:to claim that Greenman was VM myopic.
Currently in FreeBSD-5 there are far fewer people able to work on a
wide range of subsystems due to the complexity of the SMP environment.
That should be clearly obvious to everyone... I rarely see
cross-disciplinary commits (though there are other reasons for that
observation beyond the complexity of the SMP environment). Certainly
I see far fewer such commits then occured in the 4.x days.
Focus is good, but the complexity of the APIs are such that as some
of the current developers move on to other things large swaths of
code are going to start to become unattended through lack of
understanding, and it could potentially swamp the relatively few
interdisciplinary people left in the project. The SMP interactions
that John mentions are not trivial... they would challenge *ME* and
regardless of what people think about my social mores I think most
people would agree that I am a pretty good programmer.
I have no doubt that FreeBSD-5 can be stabilized with the current
development crew, but the warning signs abound and if the SMP
environmental interfaces are not simplified FreeBSD-5 will end up in
serious trouble down the line. The idea (that some people have stated
in later followups to this thread) that the APIs themselves will
stabilize is a pipedream. The codebase may become reasonably stable,
but there are a lot of things in there that people are going to want
to rewrite in coming years, and rewriting by people other then the
original authors is one of the reasons why we had so much trouble in
the 2.x and 3.x days. Look at how little VFS has been touched in the
intervening years despite the fact that it is obvious that it has needed
a serious rewrite for the last decade. I can barely figure it out even
now and I have spent hundreds of hours working on VFS.
I mean, I don't think anyone can honestly say that the scheduler is
'done', or even close to done. Look at how long the original 42 scheduler
was worked on after it was originally finished? Same goes for the VM
system, VFS, the slab allocator, the mutex related code, the USB
code (EHCI for example), and everything else.
Simplifying maintainance should be of paramount concern to everyone,
and the number one most complex issue in FreeBSD-5 right now are the
SMP related APIs and non-deterministic scheduler side effects like
preemptive cpu migration, indirect preemptive switching to
non-interrupt threads due to priority borrowing, and non deterministic
side effects from blocking in a mutex (because mutexes are used for
many things now that spl's were used for before, this is a very
serious issue).
See? I didn't mention DragonFly even once! Ooops, I didn't mention
DFly twice. oops! Well, I didn't mention it more then twice anyway.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401072317.i07NHaM9065411>