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

[Alice Ryhl <aliceryhl@google.com>]

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

Alice