Date: Thu, 18 Apr 2002 22:26:47 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: kai ouyang <oykai@msn.com> Cc: arch@FreeBSD.ORG Subject: Re: How to avoid the screen information from kernel? Message-ID: <3CBFAA97.E9AE7FA5@mindspring.com> References: <OE49pWHItq6eO6wGIa10000b12f@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
kai ouyang wrote: > > I want to know all screen information from kernel. How can I do that? I guess the subject is right and the message body is wrong? Stopping all boot information from displaying to the console is generally a matter of redefining the console as some place to which a display or serial terminal is not attached. The problem with this is that you lose all information at runtime which would normally indicate boot status, etc.. A lot of people who are using FreeBSD as the basis for their embedded systems work want to "hide" the fact that they are using FreeBSD. This is actually a mistake, for the most part, since customers really want feedback on what's happening with the box. At a past employer, I went on site to a customer facility, and for debugging purposes, enabled console messages: my employer had demanded that engineering disable boot messages to hide the underlying OS, against the recommendations of almost every engineer. One of the reasons they had to pay for me to be on site was the lack of diagnostic information meaningful to an engineer trying to fix the problem. Engineers don't know from version numbers, particularly when they are magic marketing numbers, and the release process builds something that can't be recreated from the source tree... the information shown by the UI is incredibly useless as anything but eye-candy. The customer requested -- very strongly -- that I leave the boot information visible for them when I left, and that, further, I enable it on all of our other product they had at their site. Without this, the first indication you got that the box wasn't dead was when the Tigon II card LEDs went off after having their firmware loaded, and then a "login:" prompt on the console some time after that. With a BIOS check of a huge amount of memory, the delay was considerable (the BIOS messages did not get sent to the console, either), and so there was almost no feedback to the customer that the box was working until it was actually performing the function for which it was intended. IMO, it *MAY* be useful to limit the boot time messages to failure only message, *yet still log* the messages as if they had been sent to the console. At least that way, you could get feedback. This would require a substantial reworking of the kernel print mechanism: the mechanism itself, and each instance of its use would require modification, to add a class designation parameter, so that you could "filter" classes of console messages to be displayed on the hard console (the serial port or video card or LCD display) and the soft console (the log that shows up in /var/log and in dmesg). Linux does this already. Unless such a change came from FreeBSD proper, IMO, it would be more trouble, in terms of additional maintenance overhead, to do this to "your FreeBSD derived product", than simply kicking out the messages as they currently appear. It's just not worth the hackery required... particularly for a serial console, where without initialization, the serial console output is not going to be intelligible. If you wanted to change every printf in the FreeBSD kernel to add class information, well, I'd actually be for that, assuming that you came up with a reasonable message classification system that was easy for future kernel hackers to follow. We would probably have to move "printf( ...)" into something like "kprintf( KPC_DEFAULT, ...)" to ensure that the transition could occur smoothly. It's *certainly* worth a custom/modified BIOS that prints POST information to the serial console, for things like motherboards placed in rack-mount enclosures, at least: feeback to the user that things are proceeding normally is invaluable (though the Super Micro serial BIOS POST hack leaves the console escape sequenced into color-on-same-color text, which is bad). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CBFAA97.E9AE7FA5>