Re: [PATCH v2 0/5] kthread: convert remaining users to kthread_create_worker

[Bradley Morgan]

On 5 September 2026 18:10:56 BST, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>On Sat, Sep 05, 2026 at 01:55:35PM +0100, Bradley Morgan wrote:
>> On 5 September 2026 12:19:54 BST, Greg Kroah-Hartman
>> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>> >On Fri, Sep 04, 2026 at 10:13:32PM +0100, Bradley Morgan wrote:
>> >> On 4 September 2026 22:10:32 BST, Jakub Kicinski <kuba@xxxxxxxxxx>
>> >wrote:
>> >> >On Fri, 04 Sep 2026 16:56:30 +0100 Bradley Morgan wrote:
>> >> >> On 4 September 2026 16:54:18 BST, Jakub Kicinski <kuba@xxxxxxxxxx>
>> >> >wrote:
>> >> >> >On Fri,  4 Sep 2026 09:37:21 +0000 Bradley Morgan wrote:  
>> >> >> >>   media: ivtv: convert to kthread_run_worker
>> >> >> >>   net: encx24j600: convert to kthread_run_worker
>> >> >> >>   tty: sc16is7xx: convert to kthread_run_worker
>> >> >> >>   cpufreq: schedutil: convert to kthread_create_worker  
>> >> >> >
>> >> >> >Please send these 4 to appropriate subsystems
>> >> >> >  
>> >> >> >>   kthread: remove worker->task self assignment  
>> >> >> >
>> >> >> >Then after the next merge window when trees converge send this
>one
>> >out 
>> >> >> 
>> >> >> hi, I was hoping one person could merge it with acks from all
>> >subsystems
>> >> >
>> >> >Not how this works.
>> >> Ugh, I've seen it before happen.
>> >> 
>> >> Look, fine, I'll do a V3 soon, WITH ONLY the subsystem changes, all
>> >> separate, all sent over to their respective maintainers, then when
>all
>> >> thathas been merged and there's the next merge window, then whatever,
>> >I'll
>> >> send then the kthread removal
>> >> 
>> >> IMHO this is a massive annoyance though.. because what if one of the
>> >> driverfolks doesn't wanna respond to me!?!
>> >
>> >Then, after trying for the normal way, you can make the driver change
>at
>> >the same time.  But to circumvent the "normal way" thinking it might
>not
>> >work, is not the best thing to do.
>> >
>> 
>> Greg!
>> 
>> Right, okay, Ill tell you more.
>> 
>> For features being added, where many drivers from different subsystems
>get
>> covered at once, what they tend to do is:
>> 
>> A: send all patches, rely on all maintainers to merge their own crap,
>which is a mess
>> 
>> B: Have a designated merger, who merges all the changes at once, no
>chance of regression because it's all bundled up.
>> 
>> 
>> C: send drivers first, then send the feature. So then driver maintainers
>can merge their crap, then the main feature gets merged in merge window 
>> 
>> I prefer B, because it's easier that way, akpm is usually des merger
>hence
>> I CCed him.
>> 
>> Or tip tree?
>> 
>> Honestly, if I had to be honest, C is a very annoying way, because of
>what
>> I said above, if driver maintainer thinks I'm some newbie idiot or
>> something, then what will I do? He won't merge it!
>
>To quote a longtime kernel developer years ago, "Kernel development is
>hard, let's go shopping."
>
>Sorry, but yes, it can be difficult to touch cross-subsystem stuff like
>this, always has been.  Just be patient.
>
>good luck!


Yes. Ack.


I feel this is convoluted. 

(I do mean sashiko did start crying! , sigh)


But tbh, B is the best option. For me atleast. Is C a requirement?

>
>greg k-h

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@xxxxxxxxx/