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.

> > +        // 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

Reply via email to