Date: Thu, 3 Jun 1999 19:23:53 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Brian Somers <brian@Awfulhak.org> 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 Message-ID: <199906040223.TAA01897@apollo.backplane.com> References: <199906040145.CAA04373@keep.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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 <brian@Awfulhak.org> <brian@FreeBSD.org>
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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906040223.TAA01897>