Date: Sun, 30 Apr 95 12:45 CDT From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: jkh@FreeBSD.org, hackers@FreeBSD.org Cc: uhclem@nemesis.lonestar.org Subject: Re: Revamp of probe/attach messages Message-ID: <m0s5d3U-0004vtC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
[0]any of that. I don't, however, think that the current output is [0]helpful enough to qualify as anything but noise. You guys are [0]fighting the good fight, but on entirely the wrong battlefield. An [0]entirely common syndrome among UNIX die-hards and exactly why we lost [0]the war to Microsoft. Just a FYI, but Windows 95 does produce tons of messages reporting on what it found and where it found it, unlike earlier Windows products and very similar to the BSD world. However by default, NONE of the information is shown by Windows 95. You have to hit a key (F5?) during the boot sequence, and then you are innundated with information, including any commands executed and messages from AUTOEXEC.BAT. There is also a hidden key-sequence that records all the information (including failed detection attempts and some rule information) to a log file. This very-extended info is never even shown on the screen, only in the log file. Perhaps FreeBSD might consider a similar approach, only logging the "not found" errors to a log file (perhaps not even in the standard /var/log/messages file), or only write the probe/attach data to /var/log/messages when requested. As for the "I found it and am going to use it" messages, I'd make them go to the log always, and visible during boot on demand, *IF* you feel this stuff on the screen is scaring people away from UNIX. I don't exactly believe that, but whatever. I think a "ls /bin" does more "scaring" than anything we do at boot. If you don't want to display probe/attach messages, you will need a stalling tactic, such as displaying dots or something to keep people from thinking the system is lost, much in the way that Windows 95 displays a series of marquee arrows across the bottom of the start-up screen, which you stare at for nearly 90 seconds. We could use dots, perhaps one for each device probed or attached, just so they would appear at reasonably regular intervals. SCO displays letters during kernel initialization that overwrite one another. If a SCO system hangs, you can see the last letter displayed and know roughly what it was doing when it died during boot. However, SCO displays probing information too, and it hasn't visibly hurt their sales. So, I suggest: (for when we really have time to do something like this) 1. Not displaying "Not found" and "timeout" type messages on the primary console by default. (That timeout message in the Mitsumi driver is the only message that bugs me.) 2. Writing the more detailed info to a log somewhere. 3. If the probing messages are so offensive, display them on console #2 which people already know how to get to, but boot with console #1 visible. Do something on console 1 to make it appear the boot process is proceeding. (Continue to log the probing somewhere even if on console #2.) 4. Log all probing in gory detail (-v?) to a log file other than /var/log/messages, possibly keeping only a few generations around. The thing I don't want is for the information to not be logged if I or a client doesn't happen to be there to type -v (or whatever) when the system comes back up from a power failure or other crash and some peripheral doesn't start or is not detected correctly. For that type of case, I want the "I tried but failed" info. It might help me figure out what went wrong with a peripheral without having to go there and do a cold reboot on all devices. Thanks. Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0s5d3U-0004vtC>