Message-ID: <CAJ-ks9=Jutg+UAwCVER_X91BGxWzmVq=OdStDgLZjTyMQSEX6Q@mail.gmail.com>
Date: Fri, 4 Jul 2025 07:58:27 -0400
From: Tamir Duberstein <tamird@...il.com>
To: Benno Lossin <lossin@...nel.org>
Cc: 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>, Andrew Lunn <andrew@...n.ch>, 
	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 6:09 AM Benno Lossin <lossin@...nel.org> wrote:
>
> On Fri Jul 4, 2025 at 1:23 AM CEST, Tamir Duberstein wrote:
> > On Thu, Jul 3, 2025 at 6:41 PM Tamir Duberstein <tamird@...il.com> wrote:
> >> On Thu, Jul 3, 2025 at 4:36 PM Benno Lossin <lossin@...nel.org> wrote:
> >> >
> >> > I don't understand, can't you just do:
> >> >
> >> > * add `rust/kernel/fmt.rs`,
> >> > * add `rust/macros/fmt.rs`,
> >> > * change all occurrences of `core::fmt` to `kernel::fmt` and
> >> >   `format_args!` to `fmt!`.
> >>
> >> Yes, such a split could be done - I will do so in the next spin
> >>
> >>
> >> > The last one could be split by subsystem, no? Some subsystems might
> >> > interact and thus need simultaneous splitting, but there should be some
> >> > independent ones.
> >>
> >> Yes, it probably can. As you say, some subsystems might interact - the
> >> claimed benefit of doing this subsystem-by-subsystem split is that it
> >> avoids conflicts with ongoing work that will conflict with a large
> >> patch, but this is also the downside; if ongoing work changes the set
> >> of interactions between subsystems then a maintainer may find
> >> themselves unable to emit the log message they want (because one
> >> subsystem is using kernel::fmt while another is still on core::fmt).
> >
> > I gave this a try. I ran into the problem that `format_args!` (and,
> > after this patch, `fmt!`) is at the center of `print_macro!`, which
> > itself underpins various other formatting macros. This means we'd have
> > to bifurcate the formatting infrastructure to support an incremental
> > migration. That's quite a bit of code, and likely quite a mess in the
> > resulting git history -- and that's setting aside the toil required to
> > figure out the correct combinations of subsystems that must migrate
> > together.
>
> So here is what we can do without duplicating the logic, though it
> requires multiple cycles:
>
> 1. We merge the two `fmt.rs` files & each subsystem merges an
>    implementation of `kernel::fmt::Display` for their types, but keeps
>    the `core::fmt::Display` impl around.
> 2. After all subsystems have merged the previous step, we change the
>    implementations of `print_macro!` to use `fmt!` instead of
>    `format_args!`.
> 3. We remove all occurrences of `core::fmt` (& replace them with
>    `kernel::fmt`), removing the `core::fmt::Display` impls.

That would probably work. We will probably see regressions because we
can't just replace `core::fmt` imports with `kernel::fmt`, so new code
may appear that uses the former.

I think this discussion would be productive on the next spin. The
changes in other subsystems are now almost entirely changing of import
paths -- perhaps that would be sufficiently uncontroversial for folks
to give their Acked-bys.

Powered by blists - more mailing lists