Why printk() is so complicated, and how to fix it | Hacker News Reader

Why printk() is so complicated, and how to fix it

lwn.net

90 pointsTomte13 comments

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."

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

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

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.

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.

> 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?

And in fact, you can implement the similar tricks to those used in printk(), to make a safe_printf() that works for logging in a userspace signal handler.

Because user code and kernel code are not the same, and printf is part of the standard c library, which is a userland application library.

The kernel doesn't provide a "printf" function, but provides a mostly but not completely equivalent function as "printk".

They could and perhaps should have just called it "printf", but it doesn't really matter much.

I don't think you grok what is being discussed here.

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

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

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

Reply on news.ycombinator.com