Re: [PATCH v8 02/14] rust: hrtimer: introduce hrtimer support

[Andreas Hindborg <a.hindborg@kernel.org>]

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

> On 21.02.25 13:17, Andreas Hindborg wrote:
>> "Benno Lossin" <benno.lossin@proton.me> writes:
>>
>>> On 21.02.25 11:15, Andreas Hindborg wrote:
>>>> Andreas Hindborg <a.hindborg@kernel.org> writes:
>>>>
>>>>> "Benno Lossin" <benno.lossin@proton.me> writes:
>>>>>
>>>>>> On 18.02.25 14:27, Andreas Hindborg wrote:
>>>>>>> +pub trait HrTimerCallback {
>>>>>>> +    /// The type whose [`RawHrTimerCallback::run`] method will be invoked when
>>>>>>> +    /// the timer expires.
>>>>>>> +    type CallbackTarget<'a>: RawHrTimerCallback;
>>>>>>> +
>>>>>>> +    /// This type is passed to the timer callback function. It may be a borrow
>>>>>>> +    /// of [`Self::CallbackTarget`], or it may be `Self::CallbackTarget` if the
>>>>>>> +    /// implementation can guarantee exclusive access to the target during timer
>>>>>>
>>>>>> Technically "exclusive" access is correct if the `CallbackTarget` is
>>>>>> `Pin<&Self>`, since you will get exclusive access to a `Pin<&Self>`, but
>>>>>> it might confuse people, because there can be multiple `Pin<&Self>`. So
>>>>>> I would just drop the word "exclusive" here.
>>>>>
>>>>> Yes, maybe it should be "shared or exclusive access, depending on the type"?
>>>>>
>>>>>>
>>>>>>> +    /// handler execution.
>>>>>>> +    type CallbackTargetParameter<'a>;
>>>>>>
>>>>>> Also why can't this type be an associated type of `HrTimerPointer`?
>>>>>> Since this seems to always be constrained in the impls of
>>>>>> `RawHrTimerCallback`.
>>>>>
>>>>> That might be a nice improvement, I'll try that out.
>>>>
>>>> Looking closer at this, I don't see how to achieve this. We need access
>>>> to the type here, because it is used in the signature of `run`.
>>>> `HrTimerCallback` has no bounds on it, and that is nice. If we want to
>>>> move these associated types, we have to introduce a bound here.
>>>>
>>>> We need to be generic over the type of the parameter to `run`, and by
>>>> the time the user implements this trait, the type must be known and so
>>>> the user has to specify somehow.
>>>
>>> I think if you put the associated type on the `RawHrTimerCallback`
>>> trait, it should work.
>>
>> What would be the signature of `HrTimerCallback::run` in that case?
>
>     /// Implemented by structs that can be the target of a timer callback.
>     pub trait HrTimerCallback {
>         /// The type whose [`RawHrTimerCallback::run`] method will be invoked when
>         /// the timer expires.
>         type CallbackTarget: RawHrTimerCallback;
>
>         /// Called by the timer logic when the timer fires.
>         fn run(this: <Self::CallbackTarget as RawHrTimerCallback>::CallbackTargetParameter<'_>)
>         where
>             Self: Sized;
>         // also, why does this Sized bound exist here?
>     }
>
> That should work, but now the names seem a bit long... How about:
> - CallbackTarget -> Pointer
>   - and then you can also call this the "smart pointer whose `run`
>     method will be invoked when..." in the docs
> - CallbackTargetParameter -> CallbackParameter

Right, that works. I thought you wanted to move both the associated
types.


Best regards,
Andreas Hindborg