[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250704.090751.571327900479764851.fujita.tomonori@gmail.com>
Date: Fri, 04 Jul 2025 09:07:51 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: aliceryhl@...gle.com, a.hindborg@...nel.org
Cc: fujita.tomonori@...il.com, alex.gaynor@...il.com, ojeda@...nel.org,
boqun.feng@...il.com, anna-maria@...utronix.de, bjorn3_gh@...tonmail.com,
dakr@...nel.org, frederic@...nel.org, gary@...yguo.net,
jstultz@...gle.com, linux-kernel@...r.kernel.org, lossin@...nel.org,
lyude@...hat.com, rust-for-linux@...r.kernel.org, sboyd@...nel.org,
tglx@...utronix.de, tmgross@...ch.edu
Subject: Re: [PATCH v1] rust: time: make ClockSource unsafe trait
On Wed, 2 Jul 2025 11:50:35 +0200
Alice Ryhl <aliceryhl@...gle.com> wrote:
>> >>> Mark the ClockSource trait as unsafe and document its safety
>> >>> requirements. Specifically, implementers must guarantee that their
>> >>> `ktime_get()` implementation returns a value in the inclusive range
>> >>> [0, KTIME_MAX].
>> >>>
>> >>> Update all existing implementations to use `unsafe impl` with
>> >>> corresponding safety comments.
>> >>>
>> >>> Note that there could be potential users of a customized clock source [1]
>> >>> so we don't seal the trait.
>> >>>
>> >>> Link: https://lore.kernel.org/rust-for-linux/Z9xb1r1x5tOzAIZT@boqun-archlinux/ [1]
>> >>> Suggested-by: Boqun Feng <boqun.feng@...il.com>
>> >>> Signed-off-by: FUJITA Tomonori <fujita.tomonori@...il.com>
>> >>
>> >> LGTM:
>> >> Reviewed-by: Alice Ryhl <aliceryhl@...gle.com>
>> >
>> > Thanks!
>> >
>> >> Though you're missing `` around [0; KTIME_MAX] in some places, which
>> >> may be worth adding.
>> >
>> > Andreas, would you like me to send v2 with the above changes?
>>
>> Perhaps we should use rust ranges instead [1]? Like this, no brackets: `0..=KTIME_MAX`.
>
> Well, maybe. But I think it's also worth considering just using
> english to describe it:
I had a quick look at the official Rust documentation, and I think I
agree with this opinion.
> Implementers must ensure that `ktime_get()` returns a positive value
> less than or equal to `KTIME_MAX`.
Would it make sense to explicitly mention that zero is included? Also
it would be nice to explain the value of KTIME_MAX?
Implementers must ensure that ktime_get() returns a non-negative value
less than or equal to KTIME_MAX, where KTIME_MAX equals i64::MAX.
Powered by blists - more mailing lists