Re: [RFC PATCH] sysfs: Add /sys/kernel/realtime entry

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 wrote:
> > > Hi,
> > > 
> > > 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.
> > > 
> > > Is this something that is still wanted and considered useful?
> > > Is this something that can be expressed better by other means?
> > > 
> > > There was an in person discussion about this and it was suggested to add
> > > /sys/kernel/realtime as a folder and having individual realtime features
> > > as files. I don't remember a single feature that would quality for this
> > > today but who knows. This is all I remember so far.
> > > 
> > > Now. Discussion go!
> > 
> > At the very least, it's not ok as it's not documented in
> > Documentation/ABI/ :)
> 
> :)
> 
> > But really, why is this needed?  Userspace shouldn't care, right?
> 
> So there is Clark who needed it 15y ago for some udev rules. Maybe he
> elaborate on that.
> 
> 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