Messages in this thread | | | Subject | Re: [RFC/PATCH] Documentation of kernel messages | From | holzheu <> | Date | Mon, 18 Jun 2007 15:42:34 +0200 |
| |
Hi Pavel,
On Fri, 2007-06-15 at 12:40 +0000, Pavel Machek wrote: > Hi! > > > > Your proposal is similar to one I made to some Japanese developers > > > earlier this year. I was more modest, proposing that we > > > > > > - add an enhanced printk > > > > > > xxprintk(msgid, KERN_ERR "some text %d\n", some_number); > > Maybe a stupid idea but why do we want to assign these numbers by hand? > > I can imagine it could introduce collisions when merging tons of patches > > with new messages... Wouldn't it be better to compute say, 8-byte hash > > from the message and use it as it's identifier? We could do this > > Why hashes? Just key it off full message, and treat it like normal > translation problem. > > 'lp%d: on fire' -> 'your printer failed basic tests, you should check > cabling'.
Hmmm... What about extracting all format strings from the KMSG_DOC macros and storing them in a file. E.g.:
printk("lp%d: on fire");
/** * message * * Description: * Your printer failed basic tests, you should check cabling ...
KMSG_DOC(lp, "lp%d: on fire");
Some build mechanism creates a file with all format strings of the KMSG_DOC macros:
E.g.: cat kmsgs.txt
# MSG: "lp%d: on fire" # COMPONENT: lp # DESC: Your printer failed basic tests, you should check cabling
Then we provide a tool e.g. "kmsg", which gets as input the actual kernel message and searches the message database for matching format strings:
>> kmsg "lp0: on fire" >> Your printer ...
Of course, we can get duplicate hits, too.
The advantage of that approach is, that we don't need additional message identifiers like hashes.
Michael
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |