[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72kta=Wk=3764A5SzxB6Mq=sJfm9DyMZXFC91ojUSj1TeQ@mail.gmail.com>
Date: Fri, 4 Jul 2025 10:40:43 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Tamir Duberstein <tamird@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Benno Lossin <lossin@...nel.org>,
Michal Rostecki <vadorovsky@...tonmail.com>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>, Brendan Higgins <brendan.higgins@...ux.dev>,
David Gow <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>,
Danilo Krummrich <dakr@...nel.org>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
Luis Chamberlain <mcgrof@...nel.org>, Russ Weight <russ.weight@...ux.dev>,
FUJITA Tomonori <fujita.tomonori@...il.com>, Rob Herring <robh@...nel.org>,
Saravana Kannan <saravanak@...gle.com>, Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>,
Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
Heiner Kallweit <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Bjorn Helgaas <bhelgaas@...gle.com>,
Arnd Bergmann <arnd@...db.de>, Jens Axboe <axboe@...nel.dk>,
Krzysztof Wilczyński <kwilczynski@...nel.org>,
Dave Ertman <david.m.ertman@...el.com>, Ira Weiny <ira.weiny@...el.com>,
Leon Romanovsky <leon@...nel.org>, Breno Leitao <leitao@...ian.org>,
Viresh Kumar <viresh.kumar@...aro.org>, Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
kunit-dev@...glegroups.com, dri-devel@...ts.freedesktop.org,
netdev@...r.kernel.org, devicetree@...r.kernel.org, llvm@...ts.linux.dev,
linux-pci@...r.kernel.org, nouveau@...ts.freedesktop.org,
linux-block@...r.kernel.org, linux-pm@...r.kernel.org,
linux-clk@...r.kernel.org
Subject: Re: [PATCH v13 2/5] rust: support formatting of foreign types
On Fri, Jul 4, 2025 at 12:46 AM Tamir Duberstein <tamird@...il.com> wrote:
>
> There's also a tactical question about splitting by subsystem: are
> there any tools that would assist in doing this, or is it a matter of
> manually consulting MAINTAINERS to figure out file groupings?
As Andrew mentioned, you can use that script, though I recommend not
fully/blindly trusting it.
Sometimes you will want to adjust things, e.g. sometimes things may be
related even if in a couple different `MAINTAINERS` entries, or you
may want to adjust the flags the script provides to filter, or you may
want to check `git log --no-merges` to see who is recently applying
patches related to that area, etc.
It is essentially the same process as when you send patches.
For instance, taking the diffstat above, and ignoring contents (i.e.
assuming all lines could just be freely split and without considering
other splits discussed to make the patches smaller first and reducing
the flag day changes), I could have done something like this:
drivers/block/rnull.rs | 2 +-
rust/kernel/block/mq.rs | 2 +-
drivers/gpu/nova-core/gpu.rs | 4 +-
rust/kernel/device.rs | 2 +-
rust/kernel/kunit.rs | 6 +--
rust/kernel/seq_file.rs | 2 +-
rust/kernel/fmt.rs | 89 +++++++++++++++++++++++++++++++++++++++
rust/kernel/lib.rs | 1 +
rust/kernel/prelude.rs | 3 +-
rust/kernel/print.rs | 4 +-
rust/kernel/str.rs | 22 ++++------
rust/macros/fmt.rs | 99
++++++++++++++++++++++++++++++++++++++++++++
rust/macros/lib.rs | 19 +++++++++
rust/macros/quote.rs | 7 ++++
scripts/rustdoc_test_gen.rs | 2 +-
And then those long lines may hint that it may make sense to split the
smaller tweaks in the last group into their own patch, so that it
mirrors what is done for the other smaller groups. Thus possibly
leaving the feature being added into its own patch, which would be the
biggest and the one that would take some discussion. And the others
would be the small ones that are easy to Acked-by or Reviewed-by or
simply take (if independently possible) by other maintainers.
And so on -- again, this is speaking generally, and it is just a dummy
example, not intended to say anything about the current patch. And
sometimes things may not make sense to split too far, and it can be
more annoying than it is worth for everyone involved, e.g. when we are
talking about trivial conversions that could take 50+ patches that
could be automated instead and then applied by a single maintainer.
So it is a balance.
Cheers,
Miguel
Powered by blists - more mailing lists