Date: Wed, 20 Feb 2002 19:29:29 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG, Robert Watson <rwatson@FreeBSD.ORG>, Matthew Dillon <dillon@apollo.backplane.com>, Alfred Perlstein <bright@mu.org> Subject: Re: John Balwdin's proc-locking patch Message-ID: <3C746999.7F4C6B88@mindspring.com> References: <XFMail.020220172730.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?3C746999.7F4C6B88>