Re: [PATCH 2/5] devres: export devres_node_init() and devres_node_add()

[Alice Ryhl <aliceryhl@google.com>]

On Fri, Feb 06, 2026 at 03:09:09PM +0000, Alice Ryhl wrote:
> On Fri, Feb 06, 2026 at 02:55:50PM +0100, Greg KH wrote:
> > On Fri, Feb 06, 2026 at 01:33:53PM +0000, Alice Ryhl wrote:
> > > On Fri, Feb 06, 2026 at 02:22:42PM +0100, Greg KH wrote:
> > > > On Fri, Feb 06, 2026 at 02:16:05PM +0100, Danilo Krummrich wrote:
> > > > > However, sprinkling "raw" EXPORT_SYMBOL_GPL() due to that is not great at all.
> > > > > Hence, we could do something like in [1] instead. I don't know if there are
> > > > > other options that may be better though.
> > > > > 
> > > > > [1] https://lore.kernel.org/all/DG7UR3WWZB4V.2MYMJJH1VDHH@kernel.org/
> > > > 
> > > > That's a start, but still messy.  There's no compiler options to prevent
> > > > this "lifting" of the code out of devres.rs?  If not, this is not going
> > > > to be the only problem that drivers run into like this in the future.
> > > 
> > > Because of how monomorphisation, as-is the code actually lives in the
> > > module to begin with.
> > 
> > Ok, but again, that is going to cause all sorts of "the symbol is
> > undefined" type of problems going forward as a developers just "assumes"
> > that the place where the symbol is exported will actually have the
> > symbol exported from it, not that this place will be copied inline into
> > somewhere else.
> > 
> > Think about the interaction between module symbol namespaces here.  This
> > isn't going to scale, and will trip people up and cause us to be forced
> > to export way more than we really want to (like this patch series shows,
> > I don't want to export any of these...)
> 
> Hmm. I don't know how to reconcile namespaces operating on symbols with
> monomorphisation.
> 
> We should probably think about what to do about ... :)

Matthew Maurer pointed out to me that behavior-wise exporting and
namespaces behave almost exactly the same as how Rust handles unstable
language features.

In the Rust standard library, all functions are marked with one of:

	#[unstable(feature = "feature_name_here")]
	#[stable]

when you use a #[stable] method, all is good. But if you use an unstable
method, then that's a compiler error unless you have

	#![feature(feature_name_here)]

at the crate root.

This seems equivalent to our situation here, if we consider:

* EXPORT_SYMBOL_GPL symbols are #[stable]
* un-exported symbols are #[unstable(feature = "core_kernel")]
* other namespaces are #[unstable(feature = "namespace_name_here")]

Of course the way this is enforced is through an entirely different
mechanism than symbol exports.

Alice