Linux 5.10 Begins Landing The Long Overdue Revamp Of printk()

[Raka555]

I too am not fond of watching through an hour talk on the subject. The improvements sound nice, but does printk() have much relevance / impact on your average desktop user or server install? Or is this something more useful for kernel devs / debugging?

Well the fact that most distro's now block access to dmesg for normal users should give you a hint ...

<rant>
I am still very salty about dmesg beign disabled by default.
It was a tool I used for the past 20 years to troubleshoot numerous problems.

And before everyone starts telling me I can enable it:
I do not have root rights on some of the client's servers.
To get them to enable that means submitting a change request to a committee that has almost no technical knowledge.
The answer just comes back as: "They must have been disabled for a reason"
So, now I have to log a support call to their server admins every time I need to see dmesg output...
The return times on those calls ( as these are not regarded as critical or important) are 7 days.

Why can't they just hide the dmesg output that has security implications ?
Those are 99% of the time not things normal users want to see any way ...
</rant>

[waxhead]

Cool, would you like to go over an hour of content for something you're not all that interested in? (both of those you've responded to specifically said watching an hour long video isn't desirable) If each phoronix article required an hour of my time to understand why I should care as an end-user, I don't think I'd bother to visit the site.

As a developer, I read the article and understand how the improvements are nice, but I know nothing about printk() and why I should care. You watched it, that's awesome, but your advice to two people asking about an ELI5... is that we each waste an hour of our time in hopes of an answer?

Perhaps a valid suggestion if it interests you enough to really know, for me it doesn't so if no body wants to roughly explain how it has practical benefits to readers here, I'm not going to find out and I'm ok with that

You are automatically assuming that the topic is of no interest for you or others. I was not particularly interested in this topic either, but by I decided to look at the video a bit regardless. I ended up watching the entire thing because interesting things emerged. It turns out that printk is a tad to complex to explain without more or less repeating all that is in the video so the best advice is to see it if one is interested.

[polarathene]

The answer just comes back as: "They must have been disabled for a reason"
The return times on those calls ( as these are not regarded as critical or important) are 7 days.

Eh... if it's work related, then don't stress about it, if anyone gives you shit about how long it's taking point out the recurring issues you brought up so that something can be done by it if anyone in that business chain believes it'd be of value to get the required task sorted out sooner.

Totally frustrating, I get that, but that's how businesses tend to work. One I worked for didn't care about securing an IoT product with the excuse that it's the average joe regular consumer of the product's responsibility to handle that :\ (real reason of course was to save development time and cost to get the product out faster and make shareholders happy), a common mantra relayed was "We'll deal with it if and when it becomes a problem" which is usually when it's too late and causes far more damage but w/e.

Another issue was a third-party vendor we integrated with, awful software but the boss insisted it was the best in the world, I demonstrated an open-source alternative with enterprise paid support backing if needed, was much more pleasant to use and capable, even had good response times on the open-source community channels. Wasn't convincing enough for management though, despite the recurring delays blocking progress on tasks since a support ticket response was often 2 months until a response (one that was often not that helpful). Only when nearing production stage for shipping the product did licensing costs even become considered with that vendor, well into the six figure range, so all of a sudden a meeting was held about how we should give that alternative solution I presented many months ago consideration...

You could perhaps ask the support team to setup some log forwarding to some secure location / URL you could access, perhaps even encrypting the log if needed? I think this is a solution someone I talked to a while back used. They deployed a small app with a GUI that had a button to grab the clients logs of interest, archive them into encrypted/password protected zip or similar and then the client would take that file and send it the vendor that provided that app.

[Guest]

I too am not fond of watching through an hour talk on the subject. The improvements sound nice, but does printk() have much relevance / impact on your average desktop user or server install? Or is this something more useful for kernel devs / debugging?

It's only for kernel devs/debugging. I guess they must be facing slowdowns in printk due to locking, probably during development time, or practically on servers.

[polarathene]

It's only for kernel devs/debugging. I guess they must be facing slowdowns in printk due to locking, probably during development time, or practically on servers.

Thanks for that, much appreciated! So nothing for an end-user on the desktop to care much about then

See waxhead, practically the confirmation I was asking for that doesn't require an hour watch to put into words :P

[fkoehler]

Thanks for that, much appreciated! So nothing for an end-user on the desktop to care much about then

See waxhead, practically the confirmation I was asking for that doesn't require an hour watch to put into words :P

Actually, some of the KERN_INFO / KERN_NOTICE output WAS helpful for me as a normal user, like when booting needed 300s because of nfs timeouts, which was entirely avoidable.

For a quick writeup of what printk does, see: https://cutt.ly/sglHI60

[polarathene]

Actually, some of the KERN_INFO / KERN_NOTICE output WAS helpful for me as a normal user, like when booting needed 300s because of nfs timeouts, which was entirely avoidable.

For a quick writeup of what printk does, see: https://cutt.ly/sglHI60

Yeah, I alluded to that earlier, that I assumed it was only useful for development and debugging (troubleshooting). There's no notable improvement from printk() for day to day activity as a desktop user though, not that it's not useful for when you run into a problem, but then performance of logging is rarely going to be that critical (which this update was about IIRC?)

[fkoehler]

Yeah, I alluded to that earlier, that I assumed it was only useful for development and debugging (troubleshooting). There's no notable improvement from printk() for day to day activity as a desktop user though, not that it's not useful for when you run into a problem, but then performance of logging is rarely going to be that critical (which this update was about IIRC?)

Sorry for the late answer, but if your system has logging enabled for debugging, and all major distros do OOTB, the performance of logging possibly matters for each and every Linux user, depending on how chatty your modules are and how fast your system is, even if you haven't read one line of dmesg output in your life so far. I don't know, if there are any other Linux devices than desktop systems, but for these it might realistically matter ;-)