Hacker News Reader

Comment by 0x8BADF00D | Hacker News Reader

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

View on HN

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.

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.

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

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.

Reply on news.ycombinator.com