Re: [PATCH v3 2/2] rust: add system_percpu() around the new system_percpu_wq

[Alice Ryhl <aliceryhl@google.com>]

On Tue, Feb 03, 2026 at 09:41:07AM +0100, Marco Crivellari wrote:
> On Mon, Jan 12, 2026 at 5:23 PM Alice Ryhl <aliceryhl@google.com> wrote:
> > [...]
> > > > Another approach is to add a new `enqueue_cpu` to the existing `Queue`
> > > > struct. In that case, all of these four combinations become legal:
> > > >
> > > >         workqueue::system().enqueue(my_work_item)
> > > >         workqueue::system().enqueue_cpu(my_work_item, cpu_id)
> > > >         workqueue::system_percpu().enqueue(my_work_item)
> > > >         workqueue::system_percpu().enqueue_cpu(my_work_item, cpu_id)
> > > >
> > > > which approach is best depends on whether you want all four combinations
> > > > to be legal or not.
> 
> Hi Alice,
> 
> I was starting yesterday evening when I realized the 2nd approach
> would be a better
> fit for the work we should do now. I also think in this series we
> should already convert
> the system() users to system_percpu() (same goes for system_unbound()
> => system_dfl()).
> 
> Using the 2nd approach would just make the migration smooth because we can just
> rename all the users of those functions.
> 
> I think it's better to migrate / convert to the new functions because
> they are using the new
> introduced workqueues. Sooner or later in the C code we are going to
> have warnings
> for users who are stuck on the older workqueues, so it's better to
> also migrate the Rust code
> on the newer version.
> 
> In short: I would like to introduce only enqueue_cpu() so that it's
> just easier to do a 1:1 conversion
> without changing the behavior and in the meantime introduce these renames:
> 
>     system_unbound() => system_dfl()
>     system() => system_percpu()
> 
> 
> What do you think?

I'm ok with the simpler approach.

Alice