Re: [PATCH v3] rust: hrtimer: Restrict expires() to safe contexts

FUJITA Tomonori <[email protected]> writes:

> On Wed, 15 Jul 2026 17:09:21 +0200
> Miguel Ojeda <[email protected]> wrote:
>
>> On Wed, Jul 15, 2026 at 3:37 PM Andreas Hindborg <[email protected]> wrote:
>>>
>>> Either way is fine for me, but Gary seems to gravitate towards the
>>> current solution, so maybe keep that? We can add a "// NOTE:" on the
>>> struct definition saying that soundness depends on all fields being OK
>>> with this caveat.
>> 
>> If something actually breaks, then apart from the note, what about
>> `repr(transparent)` to enforce it?
>
> Yeah, it would help. It doesn't guarantee the field stays behind
> Opaque but I don't think anyone would swap Opaque<bindings::hrtimer>
> for a bare bindings::hrtimer.

Nothing is broken by this patch. The discussion pertains to preventing
unsoundness in the future if a field is added to `HrTimer` by refactor
or something.

Making `HrTimer` transparent prevents multiple fields, which is what we
want. Adding a field to `HrTimer` that is not `Opaque` would make
acquiring `&HrTimer` from `NonNull<HrTimer>` unsound, because we can
have `&mut HrTimer` existing at the same time.

I would suggest a new version with the transparent attribute added.


Best regards,
Andreas Hindborg