Linux-kernel mailing list archive 1998-49,: Kernel messages, I18N, etc. (Was Re: [PATCH] modify console_loglevel from commandline)

# Kernel messages, I18N, etc. (Was Re: [PATCH] modify console_loglevel from commandline)

Robert Minichino (rmini@joni.pasture.net)
Wed, 9 Dec 1998 12:50:59 -0500 (EST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Gregory Maxwell: "Re: Dumb question: Which is "better" SCSI or IDE disks?"
- Previous message: John Fulmer: "Re: ATA standard[OFFTOPIC]"
- Next in thread: Bruce Korb: "Re: Kernel messages, I18N, etc. (Was Re: [PATCH] modify console_loglevel from commandline)"
- Reply: Bruce Korb: "Re: Kernel messages, I18N, etc. (Was Re: [PATCH] modify console_loglevel from commandline)"
- Reply: Robert Minichino: "Re: Kernel messages, I18N, etc. (Was Re: [PATCH] modify console_loglevel from commandline)"
- Reply: Robert Minichino: "Re: Kernel messages, I18N, etc. (Was Re: [PATCH] modify console_loglevel from commandline)"

> > cleanly towards later) allow changing the default console_loglevel
with
> > kernel parameters. These should be simple enough to include in the
> > current 2.0 and 2.1 trees without disturbing anything.
>
> There is one thing I think you need to do to go with that however. That
> is to make sure all the copyright banners printed by drivers are still
> printed in "quiet" mode. If you check that too then it seems
reasonable
> to add 'quiet'

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/

- Next message: Gregory Maxwell: "Re: Dumb question: Which is "better" SCSI or IDE disks?"
- Previous message: John Fulmer: "Re: ATA standard[OFFTOPIC]"
- Next in thread: Bruce Korb: "Re: Kernel messages, I18N, etc. (Was Re: [PATCH] modify console_loglevel from commandline)"
- Reply: Bruce Korb: "Re: Kernel messages, I18N, etc. (Was Re: [PATCH] modify console_loglevel from commandline)"
- Reply: Robert Minichino: "Re: Kernel messages, I18N, etc. (Was Re: [PATCH] modify console_loglevel from commandline)"
- Reply: Robert Minichino: "Re: Kernel messages, I18N, etc. (Was Re: [PATCH] modify console_loglevel from commandline)"