All of lore.kernel.org
 help / color / mirror / Atom feed
* Getting time in realtime kernel driver
@ 2026-05-12 16:20 François Legal
  2026-05-13  5:36 ` Jan Kiszka
  0 siblings, 1 reply; 4+ messages in thread
From: François Legal @ 2026-05-12 16:20 UTC (permalink / raw)
  To: xenomai

Hello,

I think I already asked about the same question some time ago, but I think I did not get a working answer, so here I am again.

On xenomai 3.2 + Ipipe (linux 5.4), I need to be able to get in a RT driver the current linux wall clock (impacted from NTP or PTP).
I found out I get the correct value with ktime_get_real_ts64. Was willing to use __ktime_get_real_seconds but this one is not precise enought for my application.

So my question is : is it safe to use ktime_get_real_ts64 from within an RT driver ioctl function, and if not, which API in xenomai gives the exact same time as this one ?

Thanks

François


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Getting time in realtime kernel driver
  2026-05-12 16:20 Getting time in realtime kernel driver François Legal
@ 2026-05-13  5:36 ` Jan Kiszka
  2026-05-13  7:19   ` Philippe Gerum
  0 siblings, 1 reply; 4+ messages in thread
From: Jan Kiszka @ 2026-05-13  5:36 UTC (permalink / raw)
  To: François Legal, xenomai

On 12.05.26 18:20, François Legal wrote:
> Hello,
> 
> I think I already asked about the same question some time ago, but I think I did not get a working answer, so here I am again.
> 
> On xenomai 3.2 + Ipipe (linux 5.4), I need to be able to get in a RT driver the current linux wall clock (impacted from NTP or PTP).
> I found out I get the correct value with ktime_get_real_ts64. Was willing to use __ktime_get_real_seconds but this one is not precise enought for my application.
> 
> So my question is : is it safe to use ktime_get_real_ts64 from within an RT driver ioctl function, and if not, which API in xenomai gives the exact same time as this one ?
> 

Nope, it's not safe, neither under legacy I-pipe (your kernel is dead
BTW) nor latest dovetail. Userspace access to the wallclock was hardened
for out-of-band accesses, but in-kernel had no use case, thus was never
considered.

For userland, the easiest answer is moving to a dovetail kernel and then
using CLOCK_REALTIME. Over I-pipe, we had to model this via a separate
clock named CLOCK_HOST_REALTIME.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Getting time in realtime kernel driver
  2026-05-13  5:36 ` Jan Kiszka
@ 2026-05-13  7:19   ` Philippe Gerum
  0 siblings, 0 replies; 4+ messages in thread
From: Philippe Gerum @ 2026-05-13  7:19 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: François Legal, xenomai

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 12.05.26 18:20, François Legal wrote:
>> Hello,
>> 
>> I think I already asked about the same question some time ago, but I think I did not get a working answer, so here I am again.
>> 
>> On xenomai 3.2 + Ipipe (linux 5.4), I need to be able to get in a RT driver the current linux wall clock (impacted from NTP or PTP).
>> I found out I get the correct value with ktime_get_real_ts64. Was willing to use __ktime_get_real_seconds but this one is not precise enought for my application.
>> 
>> So my question is : is it safe to use ktime_get_real_ts64 from within an RT driver ioctl function, and if not, which API in xenomai gives the exact same time as this one ?
>> 
>
> Nope, it's not safe, neither under legacy I-pipe (your kernel is dead
> BTW) nor latest dovetail. Userspace access to the wallclock was hardened
> for out-of-band accesses, but in-kernel had no use case, thus was never
> considered.
>
> For userland, the easiest answer is moving to a dovetail kernel and then
> using CLOCK_REALTIME. Over I-pipe, we had to model this via a separate
> clock named CLOCK_HOST_REALTIME.
>
> Jan

This may help:

"ktime_get_real_fast_ns: - NMI safe and fast access to clock realtime."

Caveat: with this variant, timestamp is not guaranteed to be monotonic
across an update.

-- 
Philippe.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Getting time in realtime kernel driver
       [not found] <131e-6a043e00-27-5cd69880@210449648>
@ 2026-05-13  9:23 ` Philippe Gerum
  0 siblings, 0 replies; 4+ messages in thread
From: Philippe Gerum @ 2026-05-13  9:23 UTC (permalink / raw)
  To: François Legal; +Cc: Jan Kiszka, xenomai

François Legal <francois.legal@thom.fr.eu.org> writes:

> Le Mercredi, Mai 13, 2026 09:19 CEST, Philippe Gerum <rpm@xenomai.org> a écrit: 
>  
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>> > On 12.05.26 18:20, François Legal wrote:
>> >> Hello,
>> >> 
>> >> I think I already asked about the same question some time ago, but I think I did not get a working answer, so here I am again.
>> >> 
>> >> On xenomai 3.2 + Ipipe (linux 5.4), I need to be able to get in a RT driver the current linux wall clock (impacted from NTP or PTP).
>> >> I found out I get the correct value with ktime_get_real_ts64. Was willing to use __ktime_get_real_seconds but this one is not precise enought for my application.
>> >> 
>> >> So my question is : is it safe to use ktime_get_real_ts64 from within an RT driver ioctl function, and if not, which API in xenomai gives the exact same time as this one ?
>> >> 
>> >
>> > Nope, it's not safe, neither under legacy I-pipe (your kernel is dead
>> > BTW) nor latest dovetail. Userspace access to the wallclock was hardened
>> > for out-of-band accesses, but in-kernel had no use case, thus was never
>> > considered.
>> >
>> > For userland, the easiest answer is moving to a dovetail kernel and then
>> > using CLOCK_REALTIME. Over I-pipe, we had to model this via a separate
>> > clock named CLOCK_HOST_REALTIME.
>> >
>> > Jan
>> 
>> This may help:
>> 
>> "ktime_get_real_fast_ns: - NMI safe and fast access to clock realtime."
>> 
>> Caveat: with this variant, timestamp is not guaranteed to be monotonic
>> across an update.
>> 
>> -- 
>> Philippe.
>  
> Thanks Philippe.
>
> I tried this one, but I get the same result as with __ktime_get_real_seconds, the date I get is always 1 second late (I get 52 seconds when the actual clock is at 53).
>

What is the exact content of the timespecs?

i.e. as received from:

- ktime_to_timespec64(ktime_get_real_fast_ns()) in kernel space

- clock_gettime(CLOCK_REALTIME, &ts) in userland - assuming this is the
  way you retrieve the reference clock value to compare with.

-- 
Philippe.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-05-13  9:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-12 16:20 Getting time in realtime kernel driver François Legal
2026-05-13  5:36 ` Jan Kiszka
2026-05-13  7:19   ` Philippe Gerum
     [not found] <131e-6a043e00-27-5cd69880@210449648>
2026-05-13  9:23 ` Philippe Gerum

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.