netdev - Re: [PATCH v8 3/7] rust: time: Introduce Instant type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72=vY3eZdsr12KfTCR6wGwrXyGZBk+1J7fsvg0t41ufYeA@mail.gmail.com>
Date: Sat, 18 Jan 2025 13:15:42 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: linux-kernel@...r.kernel.org, boqun.feng@...il.com, 
	rust-for-linux@...r.kernel.org, netdev@...r.kernel.org, andrew@...n.ch, 
	hkallweit1@...il.com, tmgross@...ch.edu, ojeda@...nel.org, 
	alex.gaynor@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com, 
	benno.lossin@...ton.me, a.hindborg@...sung.com, aliceryhl@...gle.com, 
	anna-maria@...utronix.de, frederic@...nel.org, tglx@...utronix.de, 
	arnd@...db.de, jstultz@...gle.com, sboyd@...nel.org, mingo@...hat.com, 
	peterz@...radead.org, juri.lelli@...hat.com, vincent.guittot@...aro.org, 
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com, 
	mgorman@...e.de, vschneid@...hat.com
Subject: Re: [PATCH v8 3/7] rust: time: Introduce Instant type

On Fri, Jan 17, 2025 at 12:31 AM FUJITA Tomonori
<fujita.tomonori@...il.com> wrote:
>
> As I wrote to Tom, that's the kernel's assumption. Do we need to make
> it an invariant too?
>
> Or improving the above "Range from 0 to `KTIME_MAX.`" is enough?
>
> The kernel assumes that the range of the ktime_t type is from 0 to
> KTIME_MAX. The ktime APIs guarantees to give a valid ktime_t.

It depends on what is best for users, i.e. if there are no use cases
where this needs to be negative, then why wouldn't we have the
invariant documented? Or do we want to make it completely opaque?

Generally speaking, I think we should pick whatever makes the most
sense for the future, since we have a chance to "do the right thing",
even if the C side is a bit different (we already use a different
name, anyway).

Thomas et al. probably know what makes the most sense here.

Cheers,
Miguel