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