Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute

[Luis Chamberlain <mcgrof@kernel.org>]

On Wed, Jun 26, 2019 at 9:51 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, Jun 26, 2019 at 03:21:08PM -0700, Luis Chamberlain wrote:
> > On Tue, Feb 5, 2019 at 2:07 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > > In lieu of no Luke Skywalker, if you will, for a large kconfig revamp
> > > on this, I'm inclined to believe *at least* having some kconfig_symb
> > > exposed for some modules is better than nothing. Christoph are you
> > > totally opposed to this effort until we get a non-reverse engineered
> > > effort in place? It just seems like an extraordinary amount of work
> > > and I'm not quite sure who's volunteering to do it.
> > >
> > > Other stakeholders may benefit from at least having some config -->
> > > module mapping for now. Not just backports or building slimmer
> > > kernels.
> >
> > Christoph, *poke*
>
> Yes, I'm still totally opposed to a half-backed hack like this.

The solution puts forward a mechanism to add a kconfig_symb where we
are 100% certain we have a direct module --> config mapping.

This is *currently* determined when the streamline_config.pl finds
that an object has only *one* associated config symbol associated. As
Cristina noted, of 62 modules on a running system 58 of them ended up
getting the kconfig_symb assigned, that is 93.5% of all modules on the
system being tested. For the other modules, if they did want this
association, we could allow a way for modules to define their own
KBUILD_KCONF variable so that this could be considered as well, or
they can look at their own kconfig stuff to try to fit the model that
does work. To be clear, the heuristics *can* be updated if there is
confidence in alternative methods for resolution. But since it is
reflective of our current situation, I cannot consider it a hack.

This implementation is a reflection of our reality in the kernel, and
as has been discussed in this thread, if we want to correct the gaps
we need to do a lot of work. And *no one* is working towards these
goals.

That said, even if you go forward with an intrusive solution like the
one you proposed we could still use the same kconfig_symb...

So no, I don't see this as a hack. It's a reflection as to our current
reality. And I cannot see how the kconfig_symb can lie or be
incorrect. So in fact I think that pushing this forward also makes the
problem statement clearer for the future of what semantics needs to be
addressed, and helps us even annotate the problematic areas of the
kernel.

What negative aspects do you see with this being merged in practice?

 Luis
--
To unsubscribe from this list: send the line "unsubscribe backports" in