Greetings, as requested this version of the kmsg patches uses a hash over the message text instead of a manually assigned message number. There is a new kernel function kmsg_printk which calculates the hash, prints the prefix together with the hash and then the message itself. Since it is impossible to add a parameter to a va_list kmsg_printk has to do two seperate printk calls. The kmsg tag now consists of the kmsg component and a 6 digit hexadecimal hash. The code uses the lower 24 bit of the Jenkins hash of the message text (there is a convenient inline implementation in include/linux/jhash.h). The likelyhood of a hash collision with 100 messages per component is ~0.03%, with 1000 messages ~3% and with 10000 messages ~95%. As an example the old xpam.3 message: xpram.3: No expanded memory available now prints as: xpram.f6ae78: No expanded memory available For translation purposes all messages need a unique id, that makes the special id 0 from the older kmsg patches rather useless. The replacement for id 0 are single line kmsg comments, e.g. /*? Tag: xpram.9a3d44 Text: " size of partition %d: %u kB\n" */ This makes the script to ignore the message, the check run will print no warning and no man pages will be generated. That leaves the question of dev_printk and friends. The dev_xxx macros prefix the message with the driver name and the device name. Both strings are dynamic, the perl script therefore can not find them which makes them unusable as part of the kmsg tag. Now there are some options how to deal with it: 1) Keep the existing dev_xxx printks, do not include a kmsg component in the printk prefix and print the hash seperately. With the hash at the start of the string an example printk would look like this: 617579: qeth: 0.0.f5f0: unknown card type The bad: the hash prefix is out of place. The large number of dev_xxx printks makes a hash collision very likely. The only solution would be to increase the number of hash digits. The message looks like crap. The good: the message check/print script works and existing code needs no change. 2) Keep the exiting dev_xxx printks, do not include a kmsg component and sneek in the hash right after the driver name. This would look like this: qeth.617579: 0.0.f5f0: unknown card type The bad: the script has no chance to find the corresponding kmsg description because the driver name is not known. Automatic message checking and man page creation would be impossible. The good: the messages look fine. 3) Keep the existing dev_xxx printks, include a kmsg component and print the hash with the component. The example from above would look like this: qeth.617579: qeth: 0.0.f5f0: unknown card type The bad: the driver name gets repeated and that every file that uses dev_xxx has to define a KMSG_COMPONENT. The message looks like crap. The good: the script works. 4) Define new kmsg_dev_xxx macros that are similar to dev_xxx, include a kmsg component. These new macros do not print the dynamic driver name, only the kmsg component. This is what is currently implemented. The example from above looks like this: qeth.617579: 0.0.f5f0: unknown card type The bad: each driver that wants to use the kmsg_dev_xxx needs to be changed. kmsg_dev_xxx in subsystems will have to do the print of the driver name in each printk as it is not included automatically. The good: the script works and the messages look fine. I still prefer option 4). Anyone with a clever idea ? -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html