Date: Thu, 20 Sep 2007 10:00:01 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Doug Ambrisko <ambrisko@ambrisko.com> Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() Message-ID: <04C1A383-2376-47DC-92A6-FA1EBF1B9E83@mac.com> In-Reply-To: <200709192257.l8JMvGAQ085614@ambrisko.com> References: <200709192257.l8JMvGAQ085614@ambrisko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?04C1A383-2376-47DC-92A6-FA1EBF1B9E83>