Re: [PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq

["Gary Guo" <gary@garyguo.net>]

On Wed Feb 4, 2026 at 9:43 AM GMT, Marco Crivellari wrote:
> On Tue, Feb 3, 2026 at 4:53 PM Gary Guo <gary@garyguo.net> wrote:
>> Hi Marco,
>>
>> The Rust change looks good to me.
>>
>> Reviewed-by: Gary Guo <gary@garyguo.net>
>
> Hi Gary,
>
> Thanks!
>
>> Is there any reason that we cannot migrate the user early by just returning
>> `system_dfl_wq` inside `system_unbound`? (I guess the question also applies on
>> why system_unbound_wq cannot be the same pointer as system_dfl_wq).
>
> The 1st version was like you mentioned, both for system() and system_unbound().
> It's one of the request made by Alice:
>
> https://lore.kernel.org/all/aL1lkN5WcWkwiq3S@google.com/
>
> To me it was ok to change with her suggestion. :-)
>
>> Also, I feel that `dfl` is not a very intuitive name. I searched the list and
>> the commit history for a while and cannot find the exact explaination on what it
>> means? Does it mean "default" or something else?
>
> Yes, "dfl" means "default".
>
> There is a huge Workqueue API refactoring. We also noticed many subsystem
> used system_wq (the - now - old per-cpu workqueue) but many of them didn't
> really benefit from per-cpu work.

Yeah, I appreciate the system -> system_percpu renaming which does make it clear
that this is percpu. However I think `system_unbound_wq` to `system_dfl_wq` is
somewhat less clear?

What is a problem to leave this still being `system_unbound`? User would need to
make a choice, and unless they know they want `percpu` it feels like natural
that they're going to use the unbounded option.

Best,
Gary

>
> So the idea was, at first, to refactor of the workqueue name changing system_wq
> to system_percpu_wq and system_unbound_wq to system_dfl_wq, to make
> clear this should be the default choice.
>
> If you want other details check this discussion:
>
> https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
>
> Thank you!