Re: [patch 1/3] kmsg: Kernel message catalog macros.

[Rick Troth]

This is really an easy thing to do.
It can be achieved without a huge retro-fit.
It can happen even without yet another macro.
(Not saying that there should not be a new macro or new function,
just that we can enjoy unique message IDs without those mechanisms.)

Martin Schwidefsky said:
> > Ok, so  a specialized version of printk will do the work to calculate
> > the hash. Only, what will we do if there ever is a conflict? The message
> > tag has to be unique. The shorter the hash is, the more likely a
> > collision gets. Don't know if 6 hash digits is enough to just ignore the
> > problem.

Point to note: the message tag has to be unique.
The tag is what's relevant, what gets catalogued.

I don't really see the value of a hash per se.
What Martin has suggested (unless I have misunderstood) is
the driver name combined with some index number ==> unique msg id.
That's not exactly a "hash".  (One can generate a hash from it,
but why bother?  You've got a unique string already.)

Then Tim Hockin wrote:
> And if you ever need to change the text that is in the format string?
> The hash changes.  That seems exactly counter to your goal...

Whether hashed or not, what's needed is premeditated reporting,
intentional dividing between variable content (like device ID)
and the explanatory text arround it.  Prefix each line with a token
(or as most are calling it, a "tag") that can be looked up off-line.

I hope no one is thinking gettext in this thread.
Don't clutter the kernel with something like gettext.

And don't burden the kernel with run-time text crunching.
Message codes go in when the module is written.
They get looked up either in user space or off-line.
Easy!  Almost trivial!

-- R;   <><

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/