3 ms·

>The 2011 Kernel Summit featured a combative session around a proposal to add a 128-bit binary tag to every kernel message. That idea, like all others before an

by scrps 5y ago

>The 2011 Kernel Summit featured a combative session around a proposal to add a 128-bit binary tag to every kernel message. That idea, like all others before and after, failed to get anywhere near the mainline. The kernel community has, quite simply, never felt the need to impose any structure on the logging information it puts out via printk(); the additional effort that would be required does not seem to be worth the cost. It seems like that was the more elegant solution vs enabling debugfs, running through the list of error messages to ensure nothing changed. How many distros even ship with debugfs enabled by default? Edit: formatting

nexuist 5y ago
I think the problem then becomes what message gets what tag and you have to bikeshed over if smaller or larger numbers mean bad/urgent messages. It's like the same problem of port allocation that IANA was created to solve. Do we really expect every kernel module to adhere to e.g. registering a unique tag with some authority for their messages? What if two separate modules print the same tag? And so and so on, and all this time of arguing over what is the "Linuxy" way to match numbers with format strings would be better used reviewing commits that could actually improve the kernel. I think the better morale of the story is to not rely on third party log output to troubleshoot problems. If you want to be notified when the CPU catches fire then you should have a daemon watching CPU temp waiting to trigger the event, not relying on some black box to log the correct line at the right time and some other black box to match the line against some ancient regex that nobody understands anymore. At the very least your temperature monitoring daemon should `printk` a message you decided upon instead of someone else.
elurg 5y ago
> How many distros even ship with debugfs enabled by default? Almost all of them, try `mount | grep ^debugs` or at least `/proc/filesystems |grep debugfs`. It's root-only though.

by scrps 5y ago

nexuist 5y ago

I think the problem then becomes what message gets what tag and you have to bikeshed over if smaller or larger numbers mean bad/urgent messages. It's like the same problem of port allocation that IANA was created to solve. Do we really expect every kernel module to adhere to e.g. registering a unique tag with some authority for their messages? What if two separate modules print the same tag? And so and so on, and all this time of arguing over what is the "Linuxy" way to match numbers with format strings would be better used reviewing commits that could actually improve the kernel. I think the better morale of the story is to not rely on third party log output to troubleshoot problems. If you want to be notified when the CPU catches fire then you should have a daemon watching CPU temp waiting to trigger the event, not relying on some black box to log the correct line at the right time and some other black box to match the line against some ancient regex that nobody understands anymore. At the very least your temperature monitoring daemon should `printk` a message you decided upon instead of someone else.

elurg 5y ago

> How many distros even ship with debugfs enabled by default? Almost all of them, try `mount | grep ^debugs` or at least `/proc/filesystems |grep debugfs`. It's root-only though.