Re: [RFC PATCH 2/3] Add generation of Module.ksymb file in streamline_config.pl

["Luis R. Rodriguez" <mcgrof@kernel.org>]

On Mon, Aug 08, 2016 at 10:32:46PM +0200, Julia Lawall wrote:
> 
> 
> On Mon, 8 Aug 2016, Luis R. Rodriguez wrote:
> 
> > On Sun, Jul 31, 2016 at 05:33:51PM +0200, Cristina Moraru wrote:
> > > Add generation of ./scripts/mod/Module.ksymb file containing
> > > associations of driver file names and corresponding CONFIG_*
> > > symbol.
> > >
> > > This file will be used by modpost to peg kconfig CONFIG_*
> > > symbol to its corresponding module. This information will
> > > be further exposed in userspace for extracting build options
> > > for the required modules.
> > >
> > > This approach faces the following limitations:
> > > * in some cases there are more than one CONFIG_* option
> > > for certain objects. This happens for the objects that are
> > > part of more CONFIGs. Thus, all configs are returned for
> > > this object names. For example, the mapping for clk_div6 is
> > > CONFIG_ARCH_R8A73A4, CONFIG_ARCH_R8A7793 and many others.
> >
> > Ah, indeed so for instance:
> >
> > drivers/clk/renesas/Makefile:
> > ...
> > obj-$(CONFIG_ARCH_R8A73A4)              += clk-r8a73a4.o clk-div6.o
> > obj-$(CONFIG_ARCH_R8A7740)              += clk-r8a7740.o clk-div6.o
> > ...
> >
> > So in this case there is no particular unique CONFIG_* symbols that
> > only associates itself to clk-div6.
> >
> > Given that the purpose here is to help compile a .config that is sufficient to
> > build a kernel with that module, I do believe using both config symbols would
> > be the appropriate solution in this case to ensure a build suffices based only
> > on this information.  This is only possible of course *iff* both symbols are
> > not mutually exclusive, so in this case an issue would be if for instance
> > CONFIG_ARCH_R8A73A4's kconfig entry negates CONFIG_ARCH_R8A7740. They do not
> > in this case so using both suffices. I can imagine doing this secondary logic
> > is cumbersome, so perhaps its best we avoid these sorts of situations as it
> > would imply doing more work going barkwards -- from modules loaded to modules
> > to symbols.
> >
> > I'd bet this would not be the only kconfig issue that could arise from this
> > loose practice in kconfig.
> >
> > Anyway, if we determine that both kconfig options should be enabled for a build
> > to select this driver -- that would increase the build size, perhaps with no
> > need for it. So this strategy of course would not yield optimal builds.
> 
> Do you care?  I guess no one would want clk-div6 for actual execution.  I
> haven't looked at the file, but from the make information, it looks like a
> library that is shared by two drivers and has no independent interest.  If
> the goal is just to be sure that the code is compiled, for sanity checking
> purposes, then wouldn't it be fine to either pick one option, or pick both
> (giving perhaps a little more confidence at a small cost).

Indeed but both kconfig options may be mutually exclusive, in such case a tool
trying to pick what should be enabled must do more work, maybe read some
Kconfig and then understand that language.

I'm a bit more inclined to close the gap and leave this ambiguity out of the
kconfig picture if possible so we have 1-1 mappings for modules at least, then
dependencies are explicit and tools doing backward mapping would not have to
learn kconfig.

  Luis