From owner-freebsd-hackers Sat Apr 29 08:54:34 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA28102 for hackers-outgoing; Sat, 29 Apr 1995 08:54:34 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA28096 for ; Sat, 29 Apr 1995 08:54:27 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.11) id JAA24821; Sat, 29 Apr 1995 09:58:26 -0600 Date: Sat, 29 Apr 1995 09:58:26 -0600 From: Nate Williams Message-Id: <199504291558.JAA24821@trout.sri.MT.net> To: "Jordan K. Hubbard" Cc: "Rodney W. Grimes" , hackers@FreeBSD.org Subject: Re: What I'd *really like* for 2.0.5 In-Reply-To: <13702.799154490@time.cdrom.com> References: <199504290650.XAA08734@gndrsh.aac.dev.com> <13702.799154490@time.cdrom.com> Sender: hackers-owner@FreeBSD.org Precedence: bulk > > The ``not found'' messages issue was debated and decided shortly after it > > was implemented. The major reason for keeping it around is that you > > know the kernel looked for the device, you know at what address it tried > > 1. Eliminate all but the "found" messages, allowing you to make kernels > with additional device support that aren't as chatty as the ones > now. > When you boot a generic kernel on a given machine, it should show you > what it finds there and nothing more. If you need more information > about what's being searched for, what's being found and what's not being > found, then I think that's a special circumstance and you should boot > with -v. Disagree, and so do Bruce and Rod. The 'not found' messages are not available to the user at runtime. > Nate has argued that "it's valuable to know what the kernel didn't find" > and I strongly disagree. It's valuable to know this WHEN YOU'RE HAVING > TROUBLE AND IT'S NOT FINDING STUFF YOU *WANT* IT TO FIND, and for every > other case it's just NOISE. But the *noise* is irrelevant IF everything works. It's when things don't work that you *need* this noise. When all of your devices are found and it works right, then nobody cares and asks questions. > I would hope that as FreeBSD's device > support gets better, and it's already fairly good (for a PC based UN*X, > anyway), we'd have less and less need to have people do anything special; > it should just work out of the box! In the exceptional cases where it > doesn't, the user can boot with -v. We need to make it *easier* for us to debug problems, not harder. > It's also foolish to debate this on the merits (or lack thereof) of our > documentation. I can readily suggest a number of truly loathsome > hacks that would easily compensate for some aspect of our system > being poorly documented, but it wouldn't make them right or > desirable. If we want to be taken seriously, then decreasing the amount of useful information given to the user is a bad thing. Just because we have lots of other bad things of similar style doesn't justify adding one more. > 2. Carefully examine each and every probe message and attempt to regularize > it to some standard form, e.g.: I doubt you'll find anyone disagreeing with you for doing this. Nate