| |||||||||||||
printk() problemsprintk() problemsPosted Jun 28, 2012 5:19 UTC (Thu) by josh (subscriber, #17465)Parent article: printk() problems
Personally, I'd rather see printk just start saying "Oh, you didn't put a newline at the end of your line, I'll put one for you."
If printk exists for debugging, it doesn't need to do fancy things like "drivername: checking for whatever ... OK"; it can just as easily say "drivername: checking for whatever" and later "drivername: whatever OK\n
(Log in to post comments)
printk() problems Posted Jun 28, 2012 11:54 UTC (Thu) by nix (subscriber, #2304) [Link]
The problem with that is that the people who wrote the printk()s meant there to be a distinction between those that ended in \n and those that did not: losing that destroys information. Now perhaps that information is not very valuable, but nonetheless it is notable that having printk() automatically append \n's would have made the boot messages on most x86-64 systems look quite horrible. If even the boot process is using this, what else is? ("A lot" is the answer.)
Linus is clearly right: the place to merge adjacent buffers when the earlier one does not end with a \n is in userspace, in the logging daemon. Logging daemons can already do duplicate elimination, rate-limiting and such things -- adjacent merging is trivial. (The kernel *also* implements a rate-limit mechanism, but that's because the buffer is limited in size and to avoid possible DoS attacks before the message ever reaches the logging daemon. Neither of these considerations apply to a trailing \n.)
printk() problems Posted Jun 28, 2012 13:05 UTC (Thu) by cesarb (subscriber, #6266) [Link]
> Linus is clearly right: the place to merge adjacent buffers when the earlier one does not end with a \n is in userspace, in the logging daemon.
The way I read Linus' message, he is advocating merging the buffers in *kernel* space ("the stuff that actually makes it to dmesg" is still in the kernel), but at the same time sending an unbuffered copy to the console. Giving us the best of both worlds, at the small cost of the screen output and dmesg output being slightly different in case multiple CPUs interleave their messages (the screen would have them interleaved, the kernel log would have them separated correctly).
printk() problems Posted Jun 28, 2012 16:09 UTC (Thu) by zlynx (subscriber, #2285) [Link]
There's a whole other problem here too. When a driver printk's some partial message and then goes off to wait on the hardware to come up, what is stopping the other driver which is running in parallel from printk'ing all over that line? Absolutely nothing, in fact.
Perhaps printk outputs need unique ID codes so the logging daemons know which bits to stick together.
Or just make each message a complete atomic entity.
printk() problems Posted Jul 5, 2012 10:33 UTC (Thu) by incase (subscriber, #37115) [Link]
> Or just make each message a complete atomic entity.
In my opinion, this is the only sane approach. Makes boot logs longer with
xyz: initializing peripheral
But doesn't interleave unrelated messages:
xyz: initializing abc: checking OK(from abc or xyz?)
|
|||||||||||||