Date: Sat, 29 Apr 1995 09:58:26 -0600 From: Nate Williams <nate@trout.sri.MT.net> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>, hackers@FreeBSD.org Subject: Re: What I'd *really like* for 2.0.5 Message-ID: <199504291558.JAA24821@trout.sri.MT.net> In-Reply-To: <13702.799154490@time.cdrom.com> References: <199504290650.XAA08734@gndrsh.aac.dev.com> <13702.799154490@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504291558.JAA24821>