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

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

[Sebastian Andrzej Siewior]

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!

---------------------8>-------------------------

From: Clark Williams <williams@redhat.com>
Date: Sat, 30 Jul 2011 21:55:53 -0500

Add a /sys/kernel entry to indicate that the kernel is a
realtime kernel.

Clark says that he needs this for udev rules, udev needs to evaluate
if its a PREEMPT_RT kernel a few thousand times and parsing uname
output is too slow or so.

Are there better solutions? Should it exist and return 0 on !-rt?

Signed-off-by: Clark Williams <williams@redhat.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 kernel/ksysfs.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index f45ade718054a..670a7a57d7b23 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -133,6 +133,15 @@ KERNEL_ATTR_RO(vmcoreinfo);
 
 #endif /* CONFIG_VMCORE_INFO */
 
+#if defined(CONFIG_PREEMPT_RT)
+static ssize_t realtime_show(struct kobject *kobj,
+			     struct kobj_attribute *attr, char *buf)
+{
+	return sprintf(buf, "%d\n", 1);
+}
+KERNEL_ATTR_RO(realtime);
+#endif
+
 /* whether file capabilities are enabled */
 static ssize_t fscaps_show(struct kobject *kobj,
 				  struct kobj_attribute *attr, char *buf)
@@ -206,6 +215,9 @@ static struct attribute * kernel_attrs[] = {
 #ifndef CONFIG_TINY_RCU
 	&rcu_expedited_attr.attr,
 	&rcu_normal_attr.attr,
+#endif
+#ifdef CONFIG_PREEMPT_RT
+	&realtime_attr.attr,
 #endif
 	NULL
 };
-- 
2.53.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Creating `/sys/kernel/realtime` as a regular file prevents future extension into a directory, permanently locking the ABI.
- [Medium] Exposing a single-purpose boolean flag instead of a generic preemption model indicator.
- [Low] Newly added sysfs show function uses deprecated `sprintf()` instead of `sysfs_emit()`.
--

--- Patch [1]: [RFC PATCH] sysfs: Add /sys/kernel/realtime entry ---
commit b40fad0ff776ab9c6dbe7fb2b7d2cb062431ad56
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

sysfs: Add /sys/kernel/realtime entry

This commit adds a /sys/kernel/realtime entry that returns 1 when PREEMPT_RT
is enabled. This provides a way for userspace tools like udev to quickly
evaluate if the system is running a realtime kernel without parsing uname
output.

> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> index f45ade718054a..670a7a57d7b23 100644
> --- a/kernel/ksysfs.c
> +++ b/kernel/ksysfs.c

[ ... ]

> @@ -133,6 +133,15 @@ KERNEL_ATTR_RO(vmcoreinfo);
>  
>  #endif /* CONFIG_VMCORE_INFO */
>  
> +#if defined(CONFIG_PREEMPT_RT)
> +static ssize_t realtime_show(struct kobject *kobj,
> +			     struct kobj_attribute *attr, char *buf)
> +{

[Severity: Medium]
The commit message asks if there are better solutions to express this state.

Instead of exposing a single-purpose boolean attribute specifically for RT,
could this be a generic preemption model indicator like
/sys/kernel/preempt_model?

The kernel supports multiple preemption models (NONE, VOLUNTARY, FULL, RT,
LAZY). Providing a unified UAPI that leverages the existing
preempt_model_str() for all configurations might be more scalable for
userspace tools than a dedicated boolean file.

> +	return sprintf(buf, "%d\n", 1);

[Severity: Low]
Should this use sysfs_emit() instead of sprintf() to align with modern sysfs
API standards?

> +}
> +KERNEL_ATTR_RO(realtime);

[Severity: Medium]
The commit message mentions a past discussion about adding
/sys/kernel/realtime as a folder. Does creating it as a regular file now
permanently lock the ABI?

If future realtime features need to be exposed individually, replacing this
regular file with a directory later would cause a strict ABI breakage. Existing
userspace tools calling read() on it would suddenly receive -EISDIR.

> +#endif
> +
>  /* whether file capabilities are enabled */
>  static ssize_t fscaps_show(struct kobject *kobj,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709143108.UYeCUUcd@linutronix.de?part=1

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

[Greg Kroah-Hartman]

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?

And checkpatch should complain about the sprintf(), should be
sysfs_emit().

thanks,

greg k-h

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

[Sebastian Andrzej Siewior]

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.

This could work with the file (or folder) or by parsing uname output. I
know of at least two individuals that switched to uname because the
upstream RT does not have that file.

cyclictest (from rt-tests) is using this file but only while collecting
system information, nothing else.
	https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/tree/src/lib/rt-utils.c#n528

There is also sosreport
	https://github.com/sosreport/sos/blob/main/sos/report/plugins/kernelrt.py#L32

using for information collection purpose.
There is thermald
	https://github.com/intel/thermal_daemon/blob/master/src/thd_engine.cpp#L1065
but this looks like just information gathering. That check looks wrong
since there is a space instead of an underline in the check so this was
not tested on a RT kernel.

> And checkpatch should complain about the sprintf(), should be
> sysfs_emit().

Sure.

> thanks,
> 
> greg k-h

Sebastian

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

[Steven Rostedt]

On Thu, 9 Jul 2026 16:46:19 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> 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?

User space most definitely does care if it's running on a real-time kernel
or not. Otherwise it may not be able to make its deadlines.

But I believe a more appropriate way is via uname, which I believe it
already does what we want:

  $ uname -a
  Linux bxtest 7.2.0-rc2-test+ #16 SMP PREEMPT_RT Thu Jul  9 11:50:36 EDT 2026 x86_64 GNU/Linux

-- Steve

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

[Clark Williams]

On Thu, Jul 09, 2026 at 05:22:14PM +0200, Sebastian Andrzej Siewior wrote:
> > 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.
> 

Ugh, I've always been embarrassed about that patch. We added it because
in the dim dark past, something triggered udev many, many times and that
called a shell script which searched the 'uname -v' output for
PREEMPT_RT, meaning boot times slowed to a crawl. Instead we added 
/sys/kernel/realtime and it just became a stat(2) call to see if the
file existed. Pretty sure that was a RHEL6 kernel (2.6.32-ish) and I
suspect that the need for it is long gone. 

I'm hesitant to call for it's removal, because the only other way for
startup code that want's to know if it's on a realtime kernel is to look
for PREEMPT_RT in the 'uname -v' output. I know that the financials and
the telcos tune specifically for RT, pretty sure there are others. 

> 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.
> 
> This could work with the file (or folder) or by parsing uname output. I
> know of at least two individuals that switched to uname because the
> upstream RT does not have that file.
> 

Really? We always took the absence of that file to mean Not Realtime.

> cyclictest (from rt-tests) is using this file but only while collecting
> system information, nothing else.
> 	https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/tree/src/lib/rt-utils.c#n528

I'll ask around, but I'm betting RTLA checks for this as well. 

> 
> There is also sosreport
> 	https://github.com/sosreport/sos/blob/main/sos/report/plugins/kernelrt.py#L32
> 

Forgot about sosreport.

> using for information collection purpose.
> There is thermald
> 	https://github.com/intel/thermal_daemon/blob/master/src/thd_engine.cpp#L1065
> but this looks like just information gathering. That check looks wrong
> since there is a space instead of an underline in the check so this was
> not tested on a RT kernel.
> 
> > And checkpatch should complain about the sprintf(), should be
> > sysfs_emit().
> 
> Sure.

I can certainly fix that.

The question I have is, would a folder with RT-specific information be useful? 
Someone just wanting to know if they're on RT could still check for existance
if that's all they want to know, but I'm not really coming up with any
other information that would prove useful for someone tuning for an RT
workload. 

Is there a "better" way to indicate that the system is running a
PREEMPT_RT kernel?

Clark

-- 
The United States Coast Guard
Ruining Natural Selection since 1790

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

[Sebastian Andrzej Siewior]

On 2026-07-09 11:02:22 [-0500], Clark Williams wrote:
> I'm hesitant to call for it's removal, because the only other way for
> startup code that want's to know if it's on a realtime kernel is to look
> for PREEMPT_RT in the 'uname -v' output. I know that the financials and
> the telcos tune specifically for RT, pretty sure there are others. 

And the "uname -v" still reveals that. Even after PREEMPT_DYNAMIC and
other changes over years.

> > 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.
> > 
> > This could work with the file (or folder) or by parsing uname output. I
> > know of at least two individuals that switched to uname because the
> > upstream RT does not have that file.
> > 
> 
> Really? We always took the absence of that file to mean Not Realtime.

The upstream (without the RT queue) never had that but uname was
working.

…
> The question I have is, would a folder with RT-specific information be useful? 

We did not have anything so far which does not mean we don't have it in
the future. The features were so far always part of a specific
subsystem and on by default on a RT system. For example PREEMPT_LAZY is
exposed via the scheduler. There is RCU-normal (not -expedited) which is
exposed via RCU. Ah. We have threaded interrupts which is not exposed at
all, you just see the threads in ps.

> Someone just wanting to know if they're on RT could still check for existance
> if that's all they want to know, but I'm not really coming up with any
> other information that would prove useful for someone tuning for an RT
> workload. 
> 
> Is there a "better" way to indicate that the system is running a
> PREEMPT_RT kernel?

I always checked for uname. Thinking about it, we could try to get a
ConditionIsRealtime for systemd unit file syntax similar to
ConditionKernelVersion and all the other things it has
	https://www.man7.org/linux/man-pages/man5/systemd.unit.5.html

That would "solve" the startup issue. It might make sense to hold off
adding the file until we have a reason to add a folder with features.
Changing it afterwards will break "test -f" users.

> Clark

Sebastian

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

[Tomas Glozar]

čt 9. 7. 2026 v 18:03 odesílatel Clark Williams <williams@redhat.com> napsal:
>
> > cyclictest (from rt-tests) is using this file but only while collecting
> > system information, nothing else.
> >       https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/tree/src/lib/rt-utils.c#n528
>
> I'll ask around, but I'm betting RTLA checks for this as well.
>

RLTA doesn't check for a realtime kernel, neither using
/sys/kernel/realtime nor PREEMPT_RT. The only mention of "non-rt" in
the code is a comment saying you will only see softirqs on non-RT.


Tomas

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

[Florian Bezdeka]

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

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

[Steven Rostedt]

On Fri, 10 Jul 2026 09:23:16 +0200
Florian Bezdeka <florian.bezdeka@siemens.com> wrote:

> 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?

Then at most it will likely just stay in the -rt patch set. As it was never
mainlined, it's not breaking any user space that uses only the mainline
kernel.

-- Steve

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

[Sebastian Andrzej Siewior]

On 2026-07-10 11:51:45 [-0400], Steven Rostedt wrote:
> On Fri, 10 Jul 2026 09:23:16 +0200
> Florian Bezdeka <florian.bezdeka@siemens.com> wrote:
> 
> > 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?
> 
> Then at most it will likely just stay in the -rt patch set. As it was never
> mainlined, it's not breaking any user space that uses only the mainline
> kernel.

And I am thinking about dropping it from -RT queue.
The -RT queue has the 8250 (which days are numbered) and i915 which is
making progress towards upstream. Therefore I want to clarify the status
of this.

> -- Steve

Sebastian

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

[Florian Bezdeka]

On Fri, 2026-07-10 at 11:51 -0400, Steven Rostedt wrote:
> On Fri, 10 Jul 2026 09:23:16 +0200
> Florian Bezdeka <florian.bezdeka@siemens.com> wrote:
> 
> > 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?
> 
> Then at most it will likely just stay in the -rt patch set. As it was never
> mainlined, it's not breaking any user space that uses only the mainline
> kernel.
> 

Depends on what you consider a valid update scenario. Updating from 6.1-
rt with sysfs available to something like 6.18 (no sysfs anymore) will
still break - as long as you do not (force) update userspace in
lockstep.

I learned meanwhile that our detection moved to uname meanwhile, so this
is not a problem for us anymore.

Florian

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

[Greg Kroah-Hartman]

On Fri, Jul 10, 2026 at 11:51:45AM -0400, Steven Rostedt wrote:
> On Fri, 10 Jul 2026 09:23:16 +0200
> Florian Bezdeka <florian.bezdeka@siemens.com> wrote:
> 
> > 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?
> 
> Then at most it will likely just stay in the -rt patch set. As it was never
> mainlined, it's not breaking any user space that uses only the mainline
> kernel.

I never said I wouldn't take it, just that if I would, it has to be
cleaned up...

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

[Steven Rostedt]

On Fri, 10 Jul 2026 18:01:20 +0200
Florian Bezdeka <florian.bezdeka@siemens.com> wrote:
> 
> Depends on what you consider a valid update scenario. Updating from 6.1-
> rt with sysfs available to something like 6.18 (no sysfs anymore) will
> still break - as long as you do not (force) update userspace in
> lockstep.

The key difference above is the drop of "-rt" in the version.

The "Don't break user space" rule is from Linus, and he only cares about
what is in his tree. It was never "some external tree supported this and
now that code from that tree is accepted in his tree, he must support this
other feature too". To get any feature in, it must be accepted by upstream
maintainers, regardless if without it, it breaks user space from the
out-of-tree code. Greg already showed his reluctance about this change.
It's people like Greg that get to decide if it gets upstream or not. In
their POV, it's *not* a regression.

> 
> I learned meanwhile that our detection moved to uname meanwhile, so this
> is not a problem for us anymore.

Then I guess it's not a problem :-)

-- Steve

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

[Steven Rostedt]

On Fri, 10 Jul 2026 18:05:12 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Fri, Jul 10, 2026 at 11:51:45AM -0400, Steven Rostedt wrote:
> > On Fri, 10 Jul 2026 09:23:16 +0200
> > Florian Bezdeka <florian.bezdeka@siemens.com> wrote:
> >   
> > > 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?  
> > 
> > Then at most it will likely just stay in the -rt patch set. As it was never
> > mainlined, it's not breaking any user space that uses only the mainline
> > kernel.  
> 
> I never said I wouldn't take it, just that if I would, it has to be
> cleaned up...

I didn't say you wouldn't take it. But you brought up a valid point about
if it is even needed. The point I'm making is that it's not a regression
from the POV of mainline maintainers (people like you and Linus).

-- Steve

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

[Sebastian Andrzej Siewior]

On 2026-07-10 18:01:20 [+0200], Florian Bezdeka wrote:
> Depends on what you consider a valid update scenario. Updating from 6.1-
> rt with sysfs available to something like 6.18 (no sysfs anymore) will
> still break - as long as you do not (force) update userspace in
> lockstep.

v6.1-RT to v6-18 no-rt will not provide the file. Also will not provide
ARM, PowerPC or 8250-nbcon support. So it is not just that single thing
that you "lose" if you don't apply the RT patch. It is just what you
notice because you don't use the other things.

> I learned meanwhile that our detection moved to uname meanwhile, so this
> is not a problem for us anymore.

Okay. So you yelled loudly that you need it, now not anymore.

So can we state that this it does not provide anything of value, is not
considered needed and can be dropped?

Clark, what is the status on your end?

I can postpone this and get back in a month or so if we need thinking
time.

> Florian

Sebastian