Re: [RFC PATCH] sysfs: Add /sys/kernel/realtime entry
Florian Bezdeka <[email protected]> Fri, 10 Jul 2026 09:23:16 +0200
| Newsgroups | org.kernel.vger.linux-rt-users,dev.linux.lists.driver-core,dev.linux.lists.linux-rt-devel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 2026-07-09 at 17:22 +0200, Sebastian Andrzej Siewior wrote: > On 2026-07-09 16:46:19 [+0200], Greg Kroah-Hartman wrote: > > On Thu, Jul 09, 2026 at 04:31:08PM +0200, Sebastian Andrzej Siewior wro= te: > > > Hi, > > >=20 > > > The following patch sat in the RT queue for almost 15years now. I can= 't > > > find its origin on the list. > > > All it does is adding /sys/kernel/realtime once PREEMPT_RT is enabled > > > and returns 1. > > >=20 > > > Is this something that is still wanted and considered useful? > > > Is this something that can be expressed better by other means? > > >=20 > > > There was an in person discussion about this and it was suggested to = add > > > /sys/kernel/realtime as a folder and having individual realtime featu= res > > > as files. I don't remember a single feature that would quality for th= is > > > today but who knows. This is all I remember so far. > > >=20 > > > Now. Discussion go! > >=20 > > At the very least, it's not ok as it's not documented in > > Documentation/ABI/ :) >=20 > :) >=20 > > But really, why is this needed?=C2=A0 Userspace shouldn't care, right? >=20 > So there is Clark who needed it 15y ago for some udev rules. Maybe he > elaborate on that. >=20 > There is custom "software" that is designed for realtime environment and > if it is run on a regular kernel then it missed its timing requirements > and the software goes usually in a fail state and people start debugging > what has happen. If this happens often enough (booting a non-RT kernel) > they tend to add a check so that the software complains early enough > since checking the kernel is usually the last thing that is done. That is an important point here, RT software should complain loudly when the environment / kernel is unexpected, so we need some kind of RT detection mechanism. uname might qualify, yes, but keep in mind that this sysfs based API is already used, so a removal might break applications. Yes, userspace can be fixed / adjusted, but it remains bad style, no? In any case we should clearly document the way how RT detection should be done - and make sure this mechanism is available in all supported stable/stable-rt trees. Florian