[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3A5036A5-EAC9-4B5D-8162-B140724CF3BF@kloenk.dev>
Date: Mon, 07 Oct 2024 10:28:02 +0200
From: Fiona Behrens <me@...enk.dev>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: netdev@...r.kernel.org, rust-for-linux@...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, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 1/6] rust: time: Implement PartialEq and
PartialOrd for Ktime
On 7 Oct 2024, at 7:37, FUJITA Tomonori 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?
Eq is basically just a marker trait, so you could argue we would never need it. I think because those 2 traits mostly just document logic it would make sense to also implement them to not create rethinking if then there is some logic that might want it and then the question is why was it omitted.
- Fiona
Powered by blists - more mailing lists