On Wed, 2026-02-11 at 12:07 +0100, Boris Brezillon wrote:
> On Wed, 11 Feb 2026 11:47:27 +0100
> Philipp Stanner <[email protected]> wrote:
>
> > On Tue, 2026-02-10 at 15:57 +0100, Boris Brezillon wrote:
> > > On Tue, 3 Feb 2026 09:14:02 +0100
> > > Philipp Stanner <[email protected]> wrote:
> > >
> > > > +/// A jobqueue Job.
> > > > +///
> > > > +/// You can stuff your data in it. The job will be borrowed back to
> > > > your driver
> > > > +/// once the time has come to run it.
> > > > +///
> > > > +/// Jobs are consumed by [`Jobqueue::submit_job`] by value (ownership
> > > > transfer).
> > > > +/// You can set multiple [`DmaFence`] as dependencies for a job. It
> > > > will only
> > > > +/// get run once all dependency fences have been signaled.
> > > > +///
> > > > +/// Jobs cost credits. Jobs will only be run if there are is enough
> > > > capacity in
> > > > +/// the jobqueue for the job's credits. It is legal to specify jobs
> > > > costing 0
> > > > +/// credits, effectively disabling that mechanism.
> > > > +#[pin_data]
> > > > +pub struct Job<T: 'static + Send> {
> > > > + cost: u32,
> > > > + #[pin]
> > > > + pub data: T,
> > > > + done_fence: Option<ARef<DmaFence<i32>>>,
> > > > + hardware_fence: Option<ARef<DmaFence<i32>>>,
> > > > + nr_of_deps: AtomicU32,
> > > > + dependencies: List<Dependency>,
> > >
> > > Given how tricky Lists are in rust, I'd recommend going for an XArray,
> > > like we have on the C side. There's a bit of overhead when the job only
> > > has a few deps, but I think simplicity beats memory-usage-optimizations
> > > in that case (especially since the overhead exists and is accepted in
> > > C).
> >
> > I mean, the list is now already implemented and works. Considering the
> > XArray would have made sense during the development difficulties.
>
> I'm sure it does, but that's still more code/tricks to maintain than
> what you'd have with the XArray abstraction.
The solution than will rather be to make the linked list implementation
better.
A list is the correct data structure in a huge number of use cases in
the kernel. We should not begin here to defer to other structures
because of convenience.
Btw. lists in Rust being so horrible has been repeatedly a reason why
some other hackers argued that Rust as a language is not suitable for
kernel development.
So getting that right seems more desirable than capitulating.
>
> >
> > If it were to make sense we could certainly replace the list with an
> > xarray, but I don't see an advantage. The JQ just needs to iterate over
> > the dependencies to register its events on them, and on drop to
> > deregister them perhaps.
> >
> > We have many jobs, but likely only few dependencies per job, so the
> > lower memory footprint seems desirable and the XArray's advantages
> > don't come to play – except maybe if we'd want to consider to avoid the
> > current unsafe-rawpointer solution to obtain the job, since obtaining a
> > job from an Xarray is far faster than by list iteration.
>
> I don't think we need O(1) for picking random deps in a job, because
> that's not something we need at all: the dep list here is used as a
> FIFO.
>
Wrong. The dep list here has no ordering requirements at all. JQ does
not care in which order it registers its events, it just cares about
dealing with dep-fences racing.
You could (de-)register your callbacks in random order, it does not
matter.
List and Xarray might be useful for the unsafe related to the
DependencyWaker. There you could avoid a raw pointer by getting the job
through a list iteration or through the hypothetical XArray.
Please take a look at my detailed code comments for DependencyWaker.
> There's the per-dep overhead of the ListLinks object maybe, but
> it's certainly acceptable. And I don't think cache locality matters
> either, because the XArray stores pointers too, so we'll still be one
> deref away from the DmaFence. No, my main concern was maintainability,
> because managing lists in rust is far from trivial, and as a developer,
> I try to avoid using concepts the language I rely on is not friendly
> with.
This would be a decision with wide implications, as detailed above.
If we were to admit that lists just don't work in Rust, then wouldn't
the consequent decision to remove them all together?
"Lists in kernel-Rust are not supported. Too difficult to maintain.
We're sorry. Use XArray et al. instead :("
