Linux 6.0 To Disable Printing On Consoles With Real-Time Kernels

[phoronix]

Phoronix: Linux 6.0 To Disable Printing On Consoles With Real-Time Kernels

As part of getting PREEMPT_RT support ready to be mainlined at long last for real-time kernel builds, a number of Linux 6.0 (nee 5.20) pull requests have revolved around additional RT preparatory changes. With the printk changes for Linux 6.0, the console drivers will now be skipped in RT mode...

https://www.phoronix.com/news/Linux-6.0-RT-Skip-Console-Print

[some_canuck]

First they take away the scrollback, now they take away the console completely... Every day linux inches towards being windows...

[wertigon]

First they take away the scrollback, now they take away the console completely... Every day linux inches towards being windows...

From My understanding it is a question of completely rewriting the console drivers, since as they are now they completely break RT.

This is only if you specifically compile an RT Linux kernel. Your standard vanilla/Debian/Arch/Fesora kernel does not need apply 🙂

[some_canuck]

From My understanding it is a question of completely rewriting the console drivers, since as they are now they completely break RT.

This is only if you specifically compile an RT Linux kernel. Your standard vanilla/Debian/Arch/Fedora kernel does not need apply 🙂

While that may be true, the AV production crowd say RT is a necessity on linux... I hope you don't run into a kernel panic or init problem on boot, because you'd never see what the issue is without a serial console.

edit: If they want to merge something that breaks everything else, they should fix the issues first instead of making everyone suffer.

[Alexmitter]

While that may be true, the AV production crowd say RT is a necessity on linux... I hope you don't run into a kernel panic or init problem on boot, because you'd never see what the issue is without a serial console.

edit: If they want to merge something that breaks everything else, they should fix the issues first instead of making everyone suffer.

Oh there is nothing broken, thats just how the console works. You can still forcefully activate it but then you will not have RT guarantees anymore and that is clearly noted.
A case where you can have your cake and eat it too is in the works already anyways and it would not make sense for the RT guys to now start the same work too.

[some_canuck]

A case where you can have your cake and eat it too is in the works already anyways and it would not make sense for the RT guys to now start the same work too.

That's fine, make RT wait then... they waited this long, what's another six months even if they don't contribute to the console fixes?

[hamishmb]

I never new scrollback existed until recently. I think they removed it for security reasons though.

[cj.wijtmans]

Its temporary until the console becomes atomic.

[wertigon]

While that may be true, the AV production crowd say RT is a necessity on linux...

Not quite true. AV requires low latency, which Realtime scheduling helps provide. This is "soft" RT and is already possible with PREEMPT_FIFO and PREEMPT_RR.

PREEMPT_RT provide Hard RT which is a different category alltogether.

As Long as the system boots user space console should be good enough until the required console changes are implemented.

[stormcrow]

Not quite true. AV requires low latency, which Realtime scheduling helps provide. This is "soft" RT and is already possible with PREEMPT_FIFO and PREEMPT_RR.

PREEMPT_RT provide Hard RT which is a different category alltogether.

As Long as the system boots user space console should be good enough until the required console changes are implemented.

It's a bit of a misconception that real time provides low latency. That might be a side effect, but it's not what real time OSes actually do. RT OSes provide guarantees for requests for attention. For example a signal comes in for attention on a certain I/O port, then the OS has a guarantee that signal will be processed within 300 ms (as an example). It doesn't mean it'll be immediately handled or nearly immediately handled as 'low latency' would imply. You can have both, or you can have either/or (guaranteed handling/low latency) depending on the platform guarantees. You can't make the assumption that one implies the other without metrics to prove it. You can have a RT OS that provides hard guarantees that all tagged requests are handled inside of 1000ms. While that's still a real time operating system, it's definitely not a low latency system (and if that's inside the system tolerances there's nothing wrong with it - and no a GP OS won't necessarily provide even a 1 second guarantee for service).

Yes, I realize you said "help" provides. I'm just explaining to others that real time doesn't necessarily imply low latency as many people seem to believe.