Thread (17 messages) 17 messages, 7 authors, 2022-10-24

Re: [PATCH v1 0/5] convert tree to get_random_u32_{below,above,between}()

From: Jakub Kicinski <kuba@kernel.org>
Date: 2022-10-22 05:32:57
Also in: linux-arm-kernel, linux-block, linux-crypto, linux-fsdevel, linux-media, linux-mips, linux-mmc, linuxppc-dev, lkml, loongarch

On Sat, 22 Oct 2022 00:23:00 -0400 Jason A. Donenfeld wrote:
quoted
How big is it?  Can you provide a stable branch to pull in the new
helpers and then everyone will be able to apply the patches to their
subsystem?  
It's a patch. But what you suggest sounds crazy to me. Supply some
branch and have every tree merge that branch separately, in duplicate,
and then get all of the conversion patches through every tree, and then
somehow coordinate the removal of the deprecated function after all of
that, and then baby sit the grand orchestration of all this over the
course of two and half months, watch it fail because of some
unmaintained corner that's affected, and then try to herd it through for
another two and a half months after that? Holy crap. That's torture.
I clean up some random networking API every couple of releases.
Unfortunately other subsystems use networking APIs too, so I have 
to do what you describe as "torture". It's not that hard in my
experience but perhaps I'm incredibly gifted. Or resilient to pain.
Were this an actually technically interesting patchset that required
some really detailed expert review, maybe that'd have some iota of
merit. But this is a really boring refactoring, mostly automated with
Coccinelle. If having to baby sit one hundred separate patches over the
course of months, handling confusion of walking maintainers through the
exercise of merging some weird duplicate branch into their trees before,
and so forth, is required to get this kind of grunt work done, I'm just
going to wind up losing all motivation for this kind of thing, and
naturally, as a matter of human nature, stop doing it. The result will
be that we have garbage pile up over time that operates on the principle
of "least hassle to deal with for the time being" rather than "love of
the code and a desire for long term maintainability and quality". The
former is sometimes how things go. The latter is what I'm striving for.

So what you suggest sounds really dreadful to me. Sorry.

Instead, this series follows the same template as the last one, and the
last one was much more nuanced and invasive and went fine. In the very
worst case, it'll require me to be on the ball with what's happening
with -next, which is something I've done before and can do again.
Not sure what you mean by "being on the ball with what's happening with
-next" surely it's Steven who'll be fixing the conflicts and paying
with his time? Or carrying extra patches because neither you will be
able to convert the new cases in your tree nor in the origin tree since
it won't have your new helpers.

To me putting the new helpers first, on a clean branch off Linus's tree
so in case of emergency it can be pulled into a random^W arbitrary tree
is just good hygiene.

But whatever. I mean - hopefully there aren't any conflicts in the ~50
networking files you touch. I just wish that people didn't pipe up with
the tree wide changes right after the merge window. Feels like the
worst possible timing.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help