linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: linux-kernel@vger.kernel.org, "Kees Cook" <keescook@chromium.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Russell King" <linux@armlinux.org.uk>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Christoph Böhmwalder" <christoph.boehmwalder@linbit.com>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Jason Gunthorpe" <jgg@nvidia.com>,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	"Andreas Dilger" <adilger.kernel@dilger.ca>,
	"Jaegeuk Kim" <jaegeuk@kernel.org>,
	"Richard Weinberger" <richard@nod.at>,
	"Darrick J . Wong" <djwong@kernel.org>,
	"SeongJae Park" <sj@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Helge Deller" <deller@gmx.de>,
	netdev@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-media@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-mmc@vger.kernel.org, linux-parisc@vger.kernel.org
Subject: Re: [PATCH v1 0/5] convert tree to get_random_u32_{below,above,between}()
Date: Sat, 22 Oct 2022 00:23:00 -0400	[thread overview]
Message-ID: <Y1NwJJOIB4gI5G11@zx2c4.com> (raw)
In-Reply-To: <20221021205522.6b56fd24@kernel.org>

On Fri, Oct 21, 2022 at 08:55:22PM -0700, Jakub Kicinski wrote:
> On Fri, 21 Oct 2022 21:43:58 -0400 Jason A. Donenfeld wrote:
> > Since get_random_u32_below() sits in my random.git tree, these patches
> > too will flow through that same tree.
> 
> 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.

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.

Jason

  reply	other threads:[~2022-10-22  4:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-22  1:43 [PATCH v1 0/5] convert tree to get_random_u32_{below,above,between}() Jason A. Donenfeld
2022-10-22  1:43 ` [PATCH v1 1/5] treewide: use get_random_u32_below() instead of deprecated function Jason A. Donenfeld
2022-10-22  2:25   ` Darrick J. Wong
2022-10-22 18:44   ` SeongJae Park
2022-10-22  1:44 ` [PATCH v1 2/5] prandom: remove prandom_u32_max() Jason A. Donenfeld
2022-10-22  1:44 ` [PATCH v1 3/5] random: add helpers for random numbers with given floor or range Jason A. Donenfeld
2022-11-14 18:04   ` Yann Droneaud
2022-11-14 18:38     ` Jason A. Donenfeld
2022-11-15  8:42       ` Yann Droneaud
2022-11-16  0:25         ` Jason A. Donenfeld
2022-10-22  1:44 ` [PATCH v1 4/5] treewide: use get_random_u32_{above,below}() instead of manual loop Jason A. Donenfeld
2022-10-22  1:44 ` [PATCH v1 5/5] treewide: use get_random_u32_between() when possible Jason A. Donenfeld
2022-10-22  3:55 ` [PATCH v1 0/5] convert tree to get_random_u32_{below,above,between}() Jakub Kicinski
2022-10-22  4:23   ` Jason A. Donenfeld [this message]
2022-10-22  5:32     ` Jakub Kicinski
2022-10-22  5:47       ` Jason A. Donenfeld
2022-10-22  6:03         ` Jakub Kicinski
2022-10-23 21:07           ` Theodore Ts'o
2022-10-24 16:43             ` Jason A. Donenfeld
2022-10-22 10:21 ` Greg Kroah-Hartman
2022-10-24 16:37 ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y1NwJJOIB4gI5G11@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoph.boehmwalder@linbit.com \
    --cc=deller@gmx.de \
    --cc=djwong@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hca@linux.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jaegeuk@kernel.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jgg@nvidia.com \
    --cc=keescook@chromium.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=loongarch@lists.linux.dev \
    --cc=martin.petersen@oracle.com \
    --cc=mpe@ellerman.id.au \
    --cc=netdev@vger.kernel.org \
    --cc=richard@nod.at \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sj@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tsbogend@alpha.franken.de \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).