linux-kernel - Re: [PATCH v13 2/5] rust: support formatting of foreign types

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <efe97ed7-dd60-4f1c-ac5c-b700300f0390@lunn.ch>
Date: Fri, 4 Jul 2025 09:57:13 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Tamir Duberstein <tamird@...il.com>
Cc: 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

> 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).

This sounds like an abstraction problem. As a developer, i just want
an API to print stuff. I don't care about what happens underneath.

Could you add an implementation of the API which uses core:fmt
underneath. Get that merged. You can then convert each subsystem one
by one to use the new API. Since all you are changing is the API, not
the implementation, there is no compatibility issues. Then, once all
users are converted to the API, you can have one patch which flips the
implementation from core:fmt to kernel:fmt. It might take you three
kernel cycles to get this done, but that is relatively fast for a tree
wide change, which sometimes takes years.

	Andrew