Nothing short of massive grunge work from my view.
There are at least a couple dozen ways of spelling "printk"
scattered about the kernel. Some of them actually use
the KERN_lvl macros, but very few really do.
Many of the wrappers around the "printk()" invocations
imply KERN_DEBUG, but they do not add that to the format strings.
Usually, those debug messages are compiled out unless
some locally defined variation of "#define DEBUG" is defined.
Basically, you must go read the subsystem code if you want
to figure out how to enable that subsystem's debug events.
> 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.
The one I did years ago was to implement a consistent three level
throttling mechanism that worked the same way across all subsystems.
Gradually, the subsystems were going to be switched to it.
The trick was that every event needed tagging of both severity
level and subsystem-of-origin. No trivial solution jumps out
at me.
> 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:
>
> [[nor would I. Remember there are around 20,000 printk's....]]
> 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,
And if a character in the format string changes (some of which are
computed at compile time)...It is also very inconvenient to
build, by hand, a table of formatting strings that are associated with
a check sum.
> Then it would be a relatively simple matter of
> hunting down all the printk()s and internationalizing them, slapping them
> in tables,
That is precisely my proposal, except that to make the
format strings findable, they have to have some
regularized formatting around them. My program only
finds about 95% of them. Any proper solution needs to be 100%.
That is where hand work comes in. That is where I balk unless
there is some reason to believe the work would get accepted.
> and making up some nice configuration options. Errors and
> other critical events could be tagged with the checksum to allow for easy
First, errors and critical events have to be identified.
There are an awful lot of very innocuous looking printk's
that lead straight up to a call to "halt()". :(
> 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.
Translations of a formatted string is a very hard problem.
You really cannot tell which parts came from the format string
and which were formatted values. One of the reasons I advocate
a binary log *in addition to* the traditional text one.
> 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.
Amen.
> I'm willing to do it or at least start it, but is it worth the effort? I
> think so. Any comments anyone?
It is worth the effort if there is reasonable expectation of adoption.
-
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/