Re: Replacing/enhancing kernel printf()
- From: Marcel Moolenaar <xcllnt@xxxxxxx>
- Date: Thu, 20 Sep 2007 10:00:01 -0700
On Sep 19, 2007, at 3:57 PM, Doug Ambrisko wrote:
As a person that has done a bunch of appliance work I wouldn't
support this. What I/other companies have done is just to mute
the console and decide on what and when messages of our own should
be displayed.
I've read this over a couple of times and it still strikes
me as an odd statement. What I posed for discussion is
exactly what you've done (or had to do) and yet you don't
support it.
What generic mechanism you proprose wouldn't meet everyone's
needs so then it is easier for them to just implement their
needs.
I didn't propose anything yet. I merely stated an example.
The intend is to find out if a generic method exists that
works for everyone, and if not, to what extend we can make
it flexible and generic without trying to meet everyone's
needs.
You advocate that people implement (and re-implement) what
they need based on the status quo. I don't see how it is
impossible to change the status quo and still have people
implement (and re-implement) what they need, provided we
don't make things impossible. In other words, if some
future infrastructure supports the status quo, no matter
how complex we make it otherwise, then your needs are met
aren't they?
I think we need to keep FreeBSD simple and selecting a
serial, vga or muted console is fine.
No, I don't think it is. For example, we already support
using all devices as console with the -D option. With EFI,
where multiple consoles can be configured this would be
a useful feature so that the OS outputs to the same devices
the firmware does.
But what about our firewire console or serial over USB?
And what about headless setups when there's only a LCD?
What I'm trying to say is that a PC-centric point of
view as a basis for a design is too limited. You already
acknowledge that, because you had to make changes and hack
the code to make it fit your needs. So, things aren't
fine according to my interpretation.
I also have a patch
so that you can tell the kernel it is a muted, serial console
since that info is lost from the loader -> kernel since
it sets console=<splat> so if console=nullconsole then the
kernel doesn't know if the serial console was muted or not.
So I made a new altconsole variable so then we set
console=nullconsole
altconsole=comconsole
so then kernel knows what console is muted.
This is very PC oriented. These variables mean nothing on
sparc64, powerpc or ia64 for example. There's nothing I
can do with what you say here.
--
Marcel Moolenaar
xcllnt@xxxxxxx
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- References:
- Re: Replacing/enhancing kernel printf()
- From: Doug Ambrisko
- Re: Replacing/enhancing kernel printf()
- Prev by Date: Re: Replacing/enhancing kernel printf()
- Next by Date: Re: Replacing/enhancing kernel printf()
- Previous by thread: Re: Replacing/enhancing kernel printf()
- Index(es):
Relevant Pages
|
|
