netdev - Re: [PATCH net-next v2 1/6] rust: time: Implement PartialEq and PartialOrd for Ktime

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: <f31d6f3e-e53c-4ced-920a-976ac44235e9@lunn.ch>
Date: Mon, 7 Oct 2024 15:15:55 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, finn@...enk.dev,
	netdev@...r.kernel.org, rust-for-linux@...r.kernel.org,
	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,
	anna-maria@...utronix.de, frederic@...nel.org, tglx@...utronix.de,
	arnd@...db.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 1/6] rust: time: Implement PartialEq and
 PartialOrd for Ktime

On Mon, Oct 07, 2024 at 10:41:23AM +0200, Alice Ryhl wrote:
> On Mon, Oct 7, 2024 at 7:37 AM FUJITA Tomonori
> <fujita.tomonori@...il.com> wrote:
> >
> > On Sun, 06 Oct 2024 12:28:59 +0200
> > Fiona Behrens <finn@...enk.dev> wrote:
> >
> > >> Implement PartialEq and PartialOrd trait for Ktime by using C's
> > >> ktime_compare function so two Ktime instances can be compared to
> > >> determine whether a timeout is met or not.
> > >
> > > Why is this only PartialEq/PartialOrd? Could we either document why or implement Eq/Ord as well?
> >
> > Because what we need to do is comparing two Ktime instances so we
> > don't need them?
> 
> When you implement PartialEq without Eq, you are telling the reader
> that this is a weird type such as floats where there exists values
> that are not equal to themselves. That's not the case here, so don't
> confuse the reader by leaving out `Eq`.
 
This might be one of those areas where there needs to be a difference
between C and Rust in terms of kernel rules. For C, there would need
to be a user. Here you seem to be saying the type system needs it, for
the type to be meaningful, even if there is no user?

Without Eq, would the compiler complain on an == operation, saying it
is not a valid operation? Is there a clear difference between nobody
has implemented this yet, vs such an operation is impossible, such as
your float example?

	Andrew