linux-kernel - Re: [PATCH v2 02/14] rust: hrtimer: introduce hrtimer support

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: <87ldziqqeo.fsf@kernel.org>
Date: Mon, 23 Sep 2024 18:35:27 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Benno Lossin" <benno.lossin@...ton.me>
Cc: "Miguel Ojeda" <ojeda@...nel.org>,  "Alex Gaynor"
 <alex.gaynor@...il.com>,  "Anna-Maria Behnsen" <anna-maria@...utronix.de>,
  "Frederic Weisbecker" <frederic@...nel.org>,  "Thomas Gleixner"
 <tglx@...utronix.de>,  "Boqun Feng" <boqun.feng@...il.com>,  "Gary Guo"
 <gary@...yguo.net>,  Björn Roy Baron
 <bjorn3_gh@...tonmail.com>,  "Alice
 Ryhl" <aliceryhl@...gle.com>,  <rust-for-linux@...r.kernel.org>,
  <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 02/14] rust: hrtimer: introduce hrtimer support

"Benno Lossin" <benno.lossin@...ton.me> writes:

> On 19.09.24 07:43, Andreas Hindborg wrote:
>> Hi Benno,
>>
>> Thanks for the feedback. I will incorporate all the whitespace
>> suggestions you have =F0=9F=91=8D
>
> There seems to be something wrong with the encoding in this email, is
> that an issue on my side or yours?

It seems to be on my end. It also showed up on lore with errors. I will
check my tools.

[...]

>>>> +    /// until the timer is unarmed and the callback has completed.
>>>> +    ///
>>>> +    /// Note: It must be safe to leak the handle.
>>>> +    type TimerHandle: TimerHandle;
>>>
>>> Why does this need to be an associated type? Couldn't we have a
>>> `TimerHandle<T>` struct? The schedule function below could then return
>>> `TimerHandle<Self>`.
>>
>> At one point, I had some cycles in trait resolution. Moving generics to
>> associated types solved that issue. Maybe this can be changed to a
>> generic. But are generics preferred over associated types for some
>> reason?
>
> The associated type is more complicated IMO, because then every
> implementer of the trait needs to create one. If we can avoid that, I
> would prefer a generic type.

When you say create, you mean specify? Users would not invent their own
type to put here, they would use the types defined by the `hrtimer`
module in later patches.

BR Andreas