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

[Greg Kroah-Hartman]

On Tue, Jul 02, 2019 at 08:51:06PM +0000, Luis Chamberlain wrote:
> On Sat, Jun 29, 2019 at 10:42:57AM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jun 28, 2019 at 11:40:22AM -0700, Luis Chamberlain wrote:
> > > On Wed, Jun 26, 2019 at 9:51 PM Christoph Hellwig <hch@xxxxxx> 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@xxxxxxxxxx> 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?
> > 
> > I'm trying to see what the actual problem that you are wanting to solve
> > here with this.  What exactly is it?
> 
> The problem is that there is no current maping of a module to respective
> kconfig symbol.

That's because it is not just "one" symbol per module.

If it were, you can just parse the Makefiles and get that single config
option for most modules, right?  But even then, multiple options can
influence a single module as to what actually gets built into that
module.

So, I would say, "who really cares"?

> > Who needs to determine the
> > "singular" configuration option that caused a kernel module to be built
> > at the expense of all other options?
> 
> Folks wanting to slim down their kernel build, and users of backports.

People who want to "slim" down things are rare, and it's usually worth
it to work backwards anyway (see what functionality is needed and then
go from there, not look at the modules themselves).  Or use a tool like
'make localmodconfig' and trim.

> > What can that be used for and who will use it?
> 
> Without a mapping there is no clean way to let you slim down your kernel
> using a distro kernel as a base, enabling only those things you really
> need.

It's hard to determine "what you really need" :)

Use localmodconfig and you have a great start, then prune from there.
Trying to put _all_ configuration dependencies in a single module isn't
going to work, our configuration language does not distill down to that.

thanks,

greg k-h