> On 21 Feb 2026, at 08:17, Alice Ryhl <[email protected]> wrote:
>
> On Thu, Feb 12, 2026 at 11:11:13AM +0100, Boris Brezillon wrote:
>>> On Wed, 11 Feb 2026 17:37:08 -0800
>>> Deborah Brouwer <[email protected]> wrote:
>>>
>>> From: Boris Brezillon <[email protected]>
>>>
>>> Introduce a generic slot manager to dynamically allocate limited hardware
>>> slots to software "seats". It can be used for both address space (AS) and
>>> command stream group (CSG) slots.
>>>
>>> The slot manager initially assigns seats to its free slots. It then
>>> continues to reuse the same slot for a seat, as long as another seat
>>> did not start to use the slot in the interim.
>>>
>>> When contention arises because all of the slots are allocated, the slot
>>> manager will lazily evict and reuse slots that have become idle (if any).
>>>
>>> The seat state is protected using the LockedBy pattern with the same lock
>>> that guards the SlotManager. This ensures the seat state stays consistent
>>> across slot operations.
>>>
>>> Hardware specific behaviour can be customized using the slot manager's
>>> `SlotOperations` trait.
>>>
>>> Signed-off-by: Boris Brezillon <[email protected]>
>>> Co-developed-by: Deborah Brouwer <[email protected]>
>>> Signed-off-by: Deborah Brouwer <[email protected]>
>
>
>>> +type LockedSeat<T, const MAX_SLOTS: usize> = LockedBy<Seat, SlotManager<T,
>>> MAX_SLOTS>>;
>>> +
>>> +impl<T: SlotOperations, const MAX_SLOTS: usize> Unpin for SlotManager<T,
>>> MAX_SLOTS> {}
>>
>> Do we really need to explicitly flag this type Unpin? I thought this
>> was the default if the struct is not pinned (and it's not AFAICT).
>
> It may be cleaner to add `#[pin_data]` to the struct and rely on the
> Unpin impl it generates.
>
> In general, the default Unpin implementation is to inherit from the
> fields. When you add #[pin_data], it's changed to only inherit from
> fields marked #[pin]. By adding #[pin_data] but not marking any fields
> #[pin], it will be Unpin unless any of the zero fields marked #[pin] are
> Unpin, i.e. it will always be Unpin.
Why do we need this if all fields are Unpin?
>
>>> + // FIXME: Annoying manual copy. The original idea was to not add
>>> Copy+Clone to SeatInfo,
>>> + // so that only slot.rs can change the seat state, but there might
>>> be better solutions
>>> + // to prevent that.
>>
>> Okay, I guess we want some inputs from Daniel and/or Alice on that one.
>
> You could consider only implementing Clone. That way, copies do not
> happen unless you do so explicitly. Or add a private method on the type
> that has the same function as Clone if you do not wish to expose it.
>
> Alice
Please check my solution where clone is not needed.
— Daniel
