From owner-freebsd-arch Wed Feb 20 19:44:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4074737B400; Wed, 20 Feb 2002 19:44:35 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1L3iXr92334; Wed, 20 Feb 2002 19:44:33 -0800 (PST) (envelope-from dillon) Date: Wed, 20 Feb 2002 19:44:33 -0800 (PST) From: Matthew Dillon Message-Id: <200202210344.g1L3iXr92334@apollo.backplane.com> To: Terry Lambert Cc: John Baldwin , Peter Wemm , arch@FreeBSD.org, Robert Watson , Alfred Perlstein Subject: Re: John Balwdin's proc-locking patch References: <3C746999.7F4C6B88@mindspring.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 :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