Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Nov 1995 23:38:00 -0800
From:      "Jordan K. Hubbard" <jkh@time.cdrom.com>
To:        Nate Williams <nate@rocky.sri.MT.net>
Cc:        Charles Henrich <henrich@crh.cl.msu.edu>, freebsd-current@freebsd.org
Subject:   Re: ISP state their FreeBSD concerns 
Message-ID:  <26335.816334680@time.cdrom.com>
In-Reply-To: Your message of "Mon, 13 Nov 1995 18:25:22 MST." <199511140125.SAA01060@rocky.sri.MT.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
> Since the VM system is *very* sensitive to even minor modifications, I
> suspect it would have taken a *very* long to review the patches, apply
> them to the system, and then test them.  Even very simple errors can
> cause *massive* corruptions, and I'm sure both David and John would
> rather avoid that for something as critical as the 2.1 release.

There's another issue, which is that David and John have been the
entire VM system development team for awhile, not to mention actively
involved in many other areas.

To put it succinctly: They need help.  We (the project) need more
kernel hackers willing to go into the labyrintian depths of the code
and carefully follow all the little chains of cause and effect that
make things happen the way they happen (or occasionally not happen,
which is when serious debugging skills are required).

This is not easy work, and I've sat on the phone with David a number
of times while he's chased a bug, listening to some of the steps
required.  Writing dozens of little test programs, carefully
engineered to cause one bug or another, loading a system to the gills
and watching it very very carefully at a number of different "test
points" to see just how it's working.  For those who've done any
serious hardware work on complex pieces of hardware, you'll know the
picture well.  You end up with the equivalent of frankenstein's lab -
various multi-channel logic analysers plugged in at different points,
an oscilloscope or two, jumpers running hither and yon.  It's not
something for the faint of heart, and being able to *read* all those
signals and say "aha!" from the faintest twitch of line A522 on some
obscure multi-channel oscilloscope trace, thus knowing the problem and
fixing it, is not a skill that grows on trees.

Maybe we should try to make the project an accredited university, then
at least those who gained such skills here could earn some recognition
for the fact in the marketplace.  CS majors could "intern" with us for
awhile.  :-)

					Jordan



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