Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Feb 2002 19:44:33 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        John Baldwin <jhb@FreeBSD.org>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, Alfred Perlstein <bright@mu.org>
Subject:   Re: John Balwdin's proc-locking patch
Message-ID:  <200202210344.g1L3iXr92334@apollo.backplane.com>
References:  <XFMail.020220172730.jhb@FreeBSD.org> <3C746999.7F4C6B88@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
    This is not contrary to my comments.  I am not saying that everything
    can be done piecemeal... in fact, I have said quite specifically that
    there are many things that CAN'T be done piecemeal.  But that has absolutely
    no relevance to my complaint, because things like ucred CAN be done
    piecemeal.  I went through John's proc patchset and I believe the number
    I came up with was that 85% of it was trivially piecemeal-able.

    My complaint, very specifically, is that P4 is being over-used and that
    is creating severe interference for everyone outside of P4.  Yes, that
    means me specifically.  And also Alfred.  A good chunk of what I've
    seen so far doesn't belong in P4 at all.  

    We are at a point in -current where great progress can be made, but if
    we stick to P4 it just isn't going to happen on a timescale that anyone
    other then a snail will be happy with.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:John Baldwin wrote:
:> Actually, I tried to do it piecemeal and ended up with a kernel that wouldn't
:> boot. :(
:
:I've done the same thing.
:
:There's a lot of code that, if it's broken into bite-sized
:chunks, loses its relevence.  Such code is only valid when
:you look at "the big picture".  Bite-sized chunks are almost
:always too small to build a big picture.
:
:The idea that you can get from any point A to any point B in
:evolutionary steps is really, really, broken.  At best, you
:get punctiuated equilibrium, and have to take hits on the
:big things as ...well, big hits of a lot of code at once.
:
:Historically, the routing code rewrite orphaned ISODE and
:X.25, the CAM code orphaned many IDE controllers and the
:AHA 1540/1542 and 1510, etc..
:
:Disruptive technology is the price of progress, and trying
:to make the transition nice and safe always is why companies
:like Shugart aren't the leading disk manufacturers today.
:
:Personally, I'd rather take the pain of a John Dyson unifying
:the VM or a Julian Elisher pounding KSE's into a square hole,
:or Kirk McKusick designing a UFS2, than trying to figure out
:how to cross the Grand Canyon with "baby steps".
:
:And it's not like the source control system couldn't let you
:back out the changes in a month, should it turn out they were
:an incredibly bad idea.  ...if they were an incredibly good
:idea, on the other hand, you're just that much farther ahead.
:
:
:I'd like to see the code committed, so that it can be pounded
:on, and I'd like to see Jonathan Lemon's sysctl for the NETISR
:removal committed and on by default, and I'd like to see the
:kernel preemption patches _in_, and I'd like to see Luigi's
:polling changes become niversal.  And those are just the obvious
:examples that leap to mind.
:
:A six month delay in all this work means a six month delay in
:everything that anyone could possibly think to build on top of
:it, and _that_ would be the real loss.
:
:-- Terry
:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202210344.g1L3iXr92334>