
Why printk() is so complicated, and how to fix it - Tomte
https://lwn.net/SubscriberLink/800946/a9ad9aba46f14e78/
======
PhantomGremlin
The article lives up to its title. Given its relatively short length, it does
a good job explaining why printk() is so complicated.

I loved this bit: _" By 2.6.26, printk() was causing large latency spikes;
kernel developers dealt with this problem by ignoring printk() in the latency
tracer, thus sweeping it under the rug."_

------
shultays
I remember one of our scholl projects was changing some stuff in the
scheduler. We were having crashes and trying figure out what was wrong using
printk

Evantually figured out it was printk that was causing the crash. Apperantly
there are parts of code you cant use printk. It was a lot of fun debugging
when each compile takes half an hour

------
crististm
One reason might be that smart? competent? people can do kernel development
without a debugger. Or so I've been told.

~~~
non-entity
From my understanding in many cases, `printk()` _is_ your debugger. I've been
told that for example, even using things like kgdb can be extremely limited if
not useless in the context of debugging device drivers

~~~
crististm
You are right. People use only what they have. They also don't contribute to
things that are actively discouraged from being used.

------
0x8BADF00D
It is way too complicated. Why have a separate function for `printk` and
`printf`? It doesn't make a whole lot of sense. Just restrict the ability to
do `printk` things with `printf` and it's not a huge deal

~~~
pilif
None of the complexity talked about in the article is about formatting and all
of the complexity is about reliability and message durability in light of all
the low-level things going on concurrently on actual hardware while still
wanting to offer an easy-to use interface and acceptable performance.

printf doesn't have to deal with any of these issues.

~~~
devit
Well, it does since calling printf in a userspace signal handler is equivalent
to calling printk in a kernel interrupt handler.

But the userspace "solution" is to just forbid such usage.

~~~
pilif
_> But the userspace "solution" is to just forbid such usage._

which is totally not something the kernel developers want because printk is
the one thing that remains even when everything else has gone belly-up.

They need a reliable method to log even under the harshest of circumstances
because without a reliable log, how should they be able to ever cause those
circumstances to not happen?

