From owner-freebsd-hackers Sat Apr 29 09:14:54 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA28481 for hackers-outgoing; Sat, 29 Apr 1995 09:14:54 -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 JAA28471 for ; Sat, 29 Apr 1995 09:14:49 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.11) id KAA24880; Sat, 29 Apr 1995 10:18:51 -0600 Date: Sat, 29 Apr 1995 10:18:51 -0600 From: Nate Williams Message-Id: <199504291618.KAA24880@trout.sri.MT.net> To: "Jordan K. Hubbard" Cc: Bruce Evans , rgrimes@gndrsh.aac.dev.com, hackers@FreeBSD.org, nate@trout.sri.MT.net, phk@ref.tfs.com Subject: Re: What I'd *really like* for 2.0.5 In-Reply-To: <14382.799171586@time.cdrom.com> References: <199504291211.WAA22625@godzilla.zeta.org.au> <14382.799171586@time.cdrom.com> Sender: hackers-owner@FreeBSD.org Precedence: bulk > > >> get found after boot if you remove the not found messages. Right > > >> now I can use dmesg or look in /var/log/messages and see it, but if > > > > >Now we're getting silly. If your system works fine then you don't care. > > >If it doesn't work, then you'll go start thinking about booting with -v. > > > > This fails for intermittent errors. > > > > Bruce > > Look guys, we're not trying to save the world in all its possible > guises - there are a number of areas in which the current messages > won't save you at all either, yet I don't see any of the proponents of > "yell in all situations" coming up with any solutions to those > problems I think the arguement is not against verbose messages so much as against removing what we consider to be still valid messages for the sake of 'cleaning' up the output. Peter Dufault's message description used in a previous email is a great example of nice output messages. If we can standardize on a way to get these messages printed when the device isn't found as well I for one would be satisfied. I think everyone agrees some of our drivers are un-necessarily verbose (some are that way now because of debugging info which I think is still necessary). If we can provide a 'verbose' flag which allows the user to turn on the really verbose flag at boot time to get these kind of errors messages it's a win. However, not having the verbose flag should not mean we don't see the devices that haven't been found. Nate