Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 3 Aug 2022 09:08:07 -0700 | Subject | Re: [GIT PULL] printk for 5.20 |
| |
On Wed, Aug 3, 2022 at 8:43 AM Petr Mladek <pmladek@suse.com> wrote: > > On Tue 2022-08-02 20:19:34, Linus Torvalds wrote: > > And printing messages to a console is not some "oh, we'll just stop > > doing that because you asked for PREEMPT_RT". > > My thinking was that PREEMPT_RT was used only by some rather small > community that was very well aware of the upstream status. I kind of > though that this was their choice.
Oh, I agree that it probably is a pretty small community.
And I also think that people who are really into RT are basically always going to have extra patches anyway - I think the bulk of the core stuff has made it upstream, but not *all* has made it.
And the "real RT" people tend to also have long lead times - it's not just about "we need guaranteed latency", it also tends to be about "our hardware is special and stays around for years" too - and likely wouldn't ever really use upstream kernels directly anyway.
In fact, I don't think anybody can currently even enable PREEMPT_RT in an upstream kernel anyway without extra patches. Much of the RT infrastructure has been merged, but some of the grottier parts are literally just "to make it easier to maintain the real external patch".
So I agree with you that in reality it probably wouldn't really affect very many people, if any.
I suspect the most immediate effect would literally be people who want to experiment with it, "just because".
Not the serious RT users who probably have special hardware anyway and are likely to also have special debug interfaces (exactly _because_ they have special latency concerns).
So that's why I'd suspect that the actual effect would be on people who just want to tinker with it, and download the necessary RT patches and set up some data acquisition station for their own use or whatever.
But thinking some more about it, even the "serious RT" people almost certainly don't really want some kind of static "disable it all". Not even if it was a separate Kconfig question like I suggested.
You'd most likely want it to be dynamic, because things like "log to console" is different at bootup when the system hasn't started yet - you can't really have realtime response when your hardware hasn't even initialized yet - and when things are actually running.
So I think even then you really just want a "turn off console logging" dynamic flag, not a Kconfig option.
Which I think we already have, in the form of log levels. No?
Linus
| |