Date: Thu, 16 Nov 2000 09:58:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: sheldonh@uunet.co.za (Sheldon Hearn) Cc: tlambert@primenet.com (Terry Lambert), will@physics.purdue.edu, arch@freebsd.org Subject: Re: Turning on debugging in GENERIC Message-ID: <200011160958.CAA02498@usr02.primenet.com> In-Reply-To: <2024.974367330@axl.fw.uunet.co.za> from "Sheldon Hearn" at Nov 16, 2000 11:35:30 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > The real point of this thread should be that a 386 taking forever > > to start up because it's not fast at generating pseudo-randomness > > is not an acceptable state of affairs. > > Terry, please think about what you're trying to achieve by posting to > his list. > > You're now arguing a point of view that relates to a completely > different thread, and one which I've already suggested has dubious value > in the here and now. Nobody else has come up with any issues that > indicate that my suggestion was flawed. > > This thread (the one you're responding on) is about the value of making > various debugging support options default in CURRENT, during the > development cycle leading up to 5.0-RELEASE. Sorry; I had an editor crash-and-burn, and was recovring via a vi -r, which lost my subject in a related posting. Please ignore the preamble section; I read one, and replied to another, based on two recovered edits. I think the build process issues are relevent to whether or not you need increased debugging, or whther you can get the information from a covert channel, like a bug report. I still think that increasing kernel spew to the DIAGNOSTIC level, at a cost of potentially very different code paths, is much less useful, in terms of getting good bug reports, than fixing the communcatons channel between the reporters and the developers would be. I would say: 1) Turn on everything but DIAGNOSTIC, since it _really_ changes the code and timings away from normal. 2) Do this in a copy of GENERIC that's used to build snapshots, not the real GENERIC, so it can be kept around and up to date (I liked the postprocessing of GENERIC suggestion, for keeping this in sync). 3) If the code path issues can be resolved, then any other options, including DIAGNOSTIC, should be heaped in, too. If they can't, though, then I think going after the bug report communcations is a better way to achieve the results I think are trying to be achieved by turning all this stuff on by default. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200011160958.CAA02498>