Where is FreeBSD going?

[Matthew Dillon]

: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