niXforums Forum Index
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   PreferencesPreferences   Log in to check your private messagesLog in to check your private messages   Log inLog in 
·  nixdoc.net ·  man pages ·  Linux HOWTOs ·  FreeBSD Tips ·  Forums
navigation Forum index » *nix » BSD » FreeBSD » mail-lists » Architecture
How to avoid the screen information from kernel?
Post new topic   Reply to topic Page 1 of 1 [2 Posts] View previous topic :: View next topic
Author Message
Terry Lambert
*nix forums Guru


Joined: 19 Mar 2002
Posts: 434

PostPosted: Fri Apr 19, 2002 3:26 am    Post subject: Re: How to avoid the screen information from kernel? Reply with quote

kai ouyang wrote:
Quote:

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
Back to top
kai ouyang
*nix forums beginner


Joined: 19 Apr 2002
Posts: 2

PostPosted: Fri Apr 19, 2002 1:49 am    Post subject: How to avoid the screen information from kernel? Reply with quote

Hi everyone,
I want to know all screen information from kernel. How can I do that?
Thanks.
Best Regards
Ouyang Kai从网站得到更多信息。MSN Explorer 免费下载:http://explorer.msn.com/lccn
Back to top
Google

Back to top
Display posts from previous:   
Post new topic   Reply to topic Page 1 of 1 [2 Posts] View previous topic :: View next topic
The time now is Thu Jan 08, 2009 5:45 am | All times are GMT
navigation Forum index » *nix » BSD » FreeBSD » mail-lists » Architecture
Jump to:  

Similar Topics
Topic Author Forum Replies Last Post
No new posts Capturing user login Information of windows sachin PHP 3 Fri Jul 21, 2006 5:44 am
No new posts Flash device can't find in kernel and redboot Kevin embedded 1 Thu Jul 20, 2006 10:04 am
No new posts panic (cpu 0) kernel memory fault - seems to point to NIC Reed, Judith Tru64 managers mail-list 0 Wed Jul 19, 2006 8:15 pm
No new posts Iptables and kernel 2.6.17 phelp needed Chavdar Videff Debian 8 Wed Jul 19, 2006 6:30 am
No new posts Playing with backported kernel Bruno Buys Debian 2 Wed Jul 19, 2006 2:10 am

Credit Report | Loans | Myspace Layouts | Hackers | Ford Cars in Milton Keynes
Copyright © 2004-2005 DeniX Solutions SRL
 
Other DeniX Solutions sites: Unix/Linux blog |  electronics forum |  medicine forum |  science forum | 
Privacy Policy


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1780s ][ Queries: 20 (0.0953s) ][ GZIP on - Debug on ]