Date: Mon, 13 May 2002 10:52:50 -0400 From: Jake Burkholder <jake@locore.ca> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: question: hacking init_main.c Message-ID: <20020513105249.K2566@locore.ca> In-Reply-To: <3CDF5EEB.ACEB8F8@mindspring.com>; from tlambert2@mindspring.com on Sun, May 12, 2002 at 11:36:27PM -0700 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> <3CDF5EEB.ACEB8F8@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Apparently, On Sun, May 12, 2002 at 11:36:27PM -0700, Terry Lambert said words to the effect of; > 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. [Peter shows i386 example in other mail] You're talking out of your ass Terry. Stop it. > > 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 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?20020513105249.K2566>