From owner-freebsd-hackers Sun Apr 30 13:10:11 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA02744 for hackers-outgoing; Sun, 30 Apr 1995 13:10:11 -0700 Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA02729 ; Sun, 30 Apr 1995 13:09:48 -0700 Received: from ast.com by relay1.UU.NET with SMTP id QQynsy05011; Sun, 30 Apr 1995 16:08:59 -0400 Received: from trsvax.fw.ast.com (fw.ast.com) by ast.com with SMTP id AA08176 (5.67b/IDA-1.5 for uunet!freebsd.org!hackers); Sun, 30 Apr 1995 13:08:56 -0700 Received: by trsvax.fw.ast.com (/\=-/\ Smail3.1.18.1 #18.1) id ; Sun, 30 Apr 95 15:09 CDT Received: by nemesis.lonestar.org (Smail3.1.27.1 #18) id m0s5d3U-0004vtC; Sun, 30 Apr 95 12:45 CDT Message-Id: Date: Sun, 30 Apr 95 12:45 CDT To: jkh@FreeBSD.org, hackers@FreeBSD.org From: uhclem@nemesis.lonestar.org (Frank Durda IV) Sent: Sun Apr 30 1995, 12:45:16 CDT Subject: Re: Revamp of probe/attach messages Cc: uhclem@nemesis.lonestar.org Sender: hackers-owner@FreeBSD.org Precedence: bulk [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 |"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