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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
