From owner-freebsd-hackers Thu Jun 3 19:25:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8064414C47 for ; Thu, 3 Jun 1999 19:25:12 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA01897; Thu, 3 Jun 1999 19:23:53 -0700 (PDT) (envelope-from dillon) Date: Thu, 3 Jun 1999 19:23:53 -0700 (PDT) From: Matthew Dillon Message-Id: <199906040223.TAA01897@apollo.backplane.com> To: Brian Somers Cc: dyson@iquest.net, ahasty@mindspring.com (Amancio Hasty), crossd@cs.rpi.edu (David E. Cross), freebsd-hackers@FreeBSD.ORG, schimken@cs.rpi.edu Subject: Re: 3.2-stable, panic #12 References: <199906040145.CAA04373@keep.lan.Awfulhak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> It wasn't the "dark side" of core, it was the panic'ed and worried :> part of core that was seeing things happening without careful review. : :The system was becoming unstable due to Matts changes. Whether the :instabilities were in Matts code or somewhere else is irrelevent. :The reaction was (IMHO) the right thing to do. : :-- :Brian This is silly. The system was not becoming unstable due to my commits. Where'd you get that from? I might have occassionally glitched something for a day or two. I think I broke build world once, blew write efficiency temporarily one time, and of the asserts added I recall only one or two panics that were due to an incorrect assert, and serveral that were due to unrelated bugs uncovered by the assert ( i.e. the assert did its job ). There might have been minor problems with 'pstat' output after the VM switchover due to the new swapper. We broke madvise() once or twice but that doesn't count because it was already badly broken before we tried to fix it, and we found several bugs in the course of trying to fix it. Not much else. Considering the amount of code committed I'd say that's a pretty good record. Most people blow things up committing just a few lines of code. And this nonsense in another email about things being untested is also complete bull. I had a machine dedicated to running test kernels 24 hours a day. I still do. In fact, I have three machines dedicated to running test kernels at the moment. Many of the VM changes underwent several days of testing before being committed, and virtually all of it was reviewed to some degree. Most of the NFS changes underwent a week or more of testing... sometimes even longer. The VM swapper underwent almost a month of testing albeit with a lot of changes in the midst of that. Testing does not locate all problems, however. This is what I mean about rumors turning into supposed facts. The fact of the matter is that what mistakes I made ( and I would argue that a certain number of mistakes are unavoidable ) were all minor. Point to one major mistake! The only alternative would have been to not touch the code at all, meaning that nothing would have gotten fixed or made more maintainable. A lot of the rewrites that supposedly contained no meaningful fixes actually do: They make the code more readable in preparation for future changes coming down the line. There is a point where emplacing a hack on top of a hack on top of a hack leads to diminishing returns and rewrite is necessary to reset the clock. I would argue that a good chunk of the code I rewrote ( which itself is only a portion of the commits made ) fall into that category. The biggest mistake that programmers working on a large project make is when they do *not* rewrite portions of the code that need to be rewritten. For a case in point you need look no further then the buffer cache and device I/O code. It's so messed up that even I could only add hacks to portions of it to implement necessary VM pager functions properly, but I sure do not intend those hacks to remain in there forever! The I/O subsystem is a holy mess. The only reason I'm not working on it right now is because I think Poul is intending to work on it later in the year. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message