4 ms·
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
by 0x8BADF00D 7y ago
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 7y agoNone 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 7y agoWell, 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.
- jlokier 7y agoAnd 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.
- pilif 7y ago> 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?
- caspper69 7y agoBecause user code and kernel code are not the same, and printf is part of the standard c library, which is a userland application library.
- newnewpdro 7y agoI don't think you grok what is being discussed here.
- devit 7y agoThe 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.
- deleted 7y ago[deleted]