That -should- be a matter of selecting the proper loglevel with printk()
for the copyright notices. Hmm. I didn't think of that one. Oops.
I just grepped and was quite disappointed. Most of the copyright
messages just use the default loglevel (KERN_WARNING), and others use
KERN_INFO. Possibly define a KERN_CPYR that's always printed to the
console, but never logged, or something like that. Any ideas?
Copyright notices that must be displayed definately do not fit into any
of the stock log severities -- syslog was meant for logging events, but
printk() is more general-purpose than that. I have run into this before
and I think there's a clean, elegant solution needed. It would certainly
tidy things up and should introduce no complexity.
I think presentation-modifying tags to printk() might be nice too. That
way printk() could present messages in an easier to read (prettier?)
format. I wouldn't mind the following:
Console Initializing
- 16 point font, 400 scanlines, colour VGA+, 80x25
- 1 virtual console, maximum 63
PCI BIOS Initializing
- BIOS32 Service Directory Structure at 0x000FACD0
- BIOS32 Service Directory Entry at 0xFB180
- PCI BIOS revision 2.10 entry at 0xFB1B0
Probing PCI hardware
Calibrating Delay Loop
- 53.25 BogoMIPS
Initializing Memory
- 62968KB available of 65528KB total
- 740KB kernel code, 384KB reserved, 1260KB data
And so on. Changing the console loglevel would then prune the less
generally useful entries from the screen. I'm willing to do any/all work
to see this through. In fact, this might coincide quite well with any
kernel internationalization.
On the topic of kernel internationalization, there is a simple solution
(IMO), but it would result in an increase in kernel size for the
non-english speaking users. Have printk() take some sort of checksum of
the message, attempt to look it up in a translation table (which, by
default, wouldn't be there), and if a translation is found, use the
translation table, otherwise use the stock message. vsprintf() could be
'fixed' to allow reordering of parameters in a not-too-messy way as
previously discussed. Then it would be a relatively simple matter of
hunting down all the printk()s and internationalizing them, slapping them
in tables, and making up some nice configuration options. Errors and
other critical events could be tagged with the checksum to allow for easy
identification. A script could be provided to convert messages back into
English for this list, the maintainer, etc. Left/right, right/left, and
alternating issues should be dealt with in the console, with the default
possibly set by an I18N option.
Some sort of extremely simple, logical, unintrusive, easy-to-remember
printk() guidelines would be quite useful IMO. It seems as if there's no
consistent usage of it through the kernel, thus no consistent way to
control the output. Just because it's text doesn't mean it HAS to be
ugly. ;) And all the pedants will be happy (MB, not Mb, mb, mB) too.
I'm willing to do it or at least start it, but is it worth the effort? I
think so. Any comments anyone?
> We have simple_strtoul() btw ... you dont need to implement atoi
Thanks, I couldn't find that; never had to use it before.
-- Robert Minichino Chief Engineer Denarius Enterprises, Inc. http://www.denarius.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/