Date: Sun, 12 May 2002 23:36:27 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Jake Burkholder <jake@locore.ca> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: question: hacking init_main.c Message-ID: <3CDF5EEB.ACEB8F8@mindspring.com> References: <Pine.BSF.4.43.0205121758360.38560-100000@BigKing.sinp.msu.ru> <3CDEB3C5.7D08D187@mindspring.com> <20020512162506.I2566@locore.ca> <3CDF4FA5.8511B01A@mindspring.com> <20020513015926.J2566@locore.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Jake Burkholder wrote: > I know that you wrote it and I know that you're wrong. > > Take sparc64_init() for example, which is called from locore.S before > mi_startup(): [ ... ] > These printfs work fine. [ ... ] > Come to think of it: > > > cd /usr/current/src/sys/ > > find . -name "*.[ch]" | xargs grep SI_SUB_CONSOLE > ./sys/kernel.h: * The SI_SUB_CONSOLE and SI_SUB_SWAP values represent values used by > ./sys/kernel.h: SI_SUB_CONSOLE = 0x0800000, /* console*/ > > > > There don't seem to be any SYSINITs that run at SI_SUB_CONSOLE. I guess your unique point of view here explains the misunderstanding... 8-). What can I say... PC hardware is stupid. The SPARC console code is handled by the PROM code. PC hardware rarely has code in the POST routines to set up a console properly (you can get AMD BIOS that has the ability to send everything out the serial consle, and assumes it's talking to a VT100, but most motherboards don't have it). If he wants to be guaranteed that it will work on any system, he needs to delay the console printf's until after the console initialization has happened, if it doesn't happen at hardware reset. Personally, I'd also suggest just printing out the subsystem and order structure elements as hex, rather than relying on strings having been defined (or add a string element to the sysinit structure itself). Normally, when I do this, I just put out the hex codes. I've done this more than once (e.g. adding a 4M page allocation type to the kernel, etc.). Actually, it would be nice to be able to set these flags into some global context somewhere, and then use it when doing the printf()'s, so that you could give a list of subsystems whose printf's you wanted to ignore. In my experience, it's a common thing for managers to want to suppress many of the boot messages from appearing on the console, so as to hide the fact that they are using FreeBSD... never mind the fact that this makes field diagnostics a real pain for the engineers (I said it was common to want it ... not clever... 8-)). Really, there wants to be a seperation of the console from the dmesg from the klog for messages, so you can select what goes where (or if it goes at all). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CDF5EEB.ACEB8F8>