Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1464737 > unrolled thread

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

Started byCristina Moraru <cristina.moraru09@gmail.com>
First post2016-08-17 21:30 +0200
Last post2016-08-25 22:40 +0200
Articles 6 on this page of 26 — 7 participants

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH 0/5] Add CONFIG symbol as module attribute Cristina Moraru <cristina.moraru09@gmail.com> - 2016-08-17 21:30 +0200
    [RFC PATCH 2/5] Add CONFIG symbol to module as compilation parameter Cristina Moraru <cristina.moraru09@gmail.com> - 2016-08-17 21:30 +0200
      Re: [RFC PATCH 2/5] Add CONFIG symbol to module as compilation  parameter "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-19 03:00 +0200
        Re: [RFC PATCH 2/5] Add CONFIG symbol to module as compilation  parameter "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-19 03:40 +0200
        Re: [RFC PATCH 2/5] Add CONFIG symbol to module as compilation parameter Cristina-Gabriela Moraru <cristina.moraru09@gmail.com> - 2016-08-20 17:20 +0200
          Re: [RFC PATCH 2/5] Add CONFIG symbol to module as compilation  parameter "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-23 21:20 +0200
    [RFC PATCH 4/5] Set KCONFIG_KSYMB as value for kconfig_ksymb module attribute Cristina Moraru <cristina.moraru09@gmail.com> - 2016-08-17 21:30 +0200
      Re: [RFC PATCH 4/5] Set KCONFIG_KSYMB as value for kconfig_ksymb  module attribute "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-19 04:10 +0200
        Re: [RFC PATCH 4/5] Set KCONFIG_KSYMB as value for kconfig_ksymb  module attribute Cristina-Gabriela Moraru <cristina.moraru09@gmail.com> - 2016-08-20 17:20 +0200
          Re: [RFC PATCH 4/5] Set KCONFIG_KSYMB as value for kconfig_ksymb  module attribute "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-23 21:20 +0200
    [RFC PATCH 3/5] Trigger Module.ksymb generation in Makefile Cristina Moraru <cristina.moraru09@gmail.com> - 2016-08-17 21:30 +0200
      Re: [RFC PATCH 3/5] Trigger Module.ksymb generation in Makefile "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-18 21:50 +0200
    Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-19 04:10 +0200
      Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute Michal Marek <mmarek@suse.com> - 2016-08-19 11:10 +0200
        Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute Cristina-Gabriela Moraru <cristina.moraru09@gmail.com> - 2016-08-22 21:50 +0200
        Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-23 23:40 +0200
          Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute Michal Marek <mmarek@suse.com> - 2016-08-24 13:10 +0200
            Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-24 18:40 +0200
              Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute Naveen Kumar <nk1383886@gmail.com> - 2016-08-24 19:40 +0200
      Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute Cristina-Gabriela Moraru <cristina.moraru09@gmail.com> - 2016-08-22 21:40 +0200
        Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-23 21:20 +0200
      Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute Christoph Hellwig <hch@lst.de> - 2016-08-25 09:50 +0200
        Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute Johannes Berg <johannes@sipsolutions.net> - 2016-08-25 10:40 +0200
          Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-25 22:00 +0200
        Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute Michal Marek <mmarek@suse.com> - 2016-08-25 10:50 +0200
        Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-25 22:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1468788

From"Luis R. Rodriguez" <mcgrof@kernel.org>
Date2016-08-23 21:20 +0200
Message-ID<s9poR-8bI-9@gated-at.bofh.it>
In reply to#1468000
On Mon, Aug 22, 2016 at 09:35:47PM +0200, Cristina-Gabriela Moraru wrote:
> 2016-08-18 19:55 GMT+02:00 Luis R. Rodriguez <mcgrof@kernel.org>:
> > On Wed, Aug 17, 2016 at 09:26:58PM +0200, Cristina Moraru wrote:
> >
> >> This patchset implements dynamic pegging of kconfig symbol
> >> into driver modinfo section
> >
> > First a little bit of motivation here helps, so let me try to
> > help fill in some gaps. This may help explain what you have
> > been working on a bit more.
> >
> > First, for those that were not Cc'd but curious about this work
> > so far, you can read the patches here:
> >
> > Original cover letter:
> >
> > https://lkml.kernel.org/r/1471462023-119645-1-git-send-email-cristina.moraru09@gmail.com
> >
> > https://marc.info/?l=linux-kernel&m=147146213519750&w=2 - patch 1
> > https://marc.info/?l=linux-kernel&m=147146209019744&w=2 - patch 2
> > https://marc.info/?l=linux-kernel&m=147146211819747&w=2 - patch 3
> > https://marc.info/?l=linux-kernel&m=147146209119745&w=2 - patch 4
> > https://marc.info/?l=linux-kernel&m=147146209519746&w=2 - patch 5
> >
> > There are a few situations in which you may want to extract a
> > subset of Kconfig CONFIG_* symbols for a system. At least when
> > only considering modules:
> >
> >  a) When optimizing build requirements for a kernel for a system.
> >     That is you boot into a distro kernel and then want to build
> >     a slim kernel only with sensible kernel configuration options.
> >
> >  b) When you are on a distribution kernel but the distribution
> >     kernel provided lacks hardware support for your device, you
> >     may either want to upgrade the full kernel in which case you
> >     want to do a) or -- you may want to just a backports release
> >     which provides just the modules you need, you'd use it on top
> >     of the distribution kernel.
> >
> > Are there other *uses* outside of the two above for having a direct
> > deterministic mapping between module and a kconfig symbol ? What
> > if we could also do this for built-in code as well ? kconfig-sat [0] is
> > work that is still being ironed out, but if that was in place and we
> > handed it a set of required options we want, it should in theory help
> > resolve the dependencies to give us a functional .config for a kernel.
> > This of course is a long term possible goal just used as an example
> > -- but are there other uses?
> >
> I can't think of any examples. I will add this ones in the cover
> letter as motivation.

Michal provided one more :) -- which was actually a side goal you had I think.

Very clearly documenting the motivation is very important here, side benefits
that you can think of are (some listed above) should help understand why
we may went to or not do some further enhancements to build system to help
with more deterministic backwards mappings.

> > To be clear, you only peg the CONFIG_ option if you are
> > 100% certain of having a direct mapping, is that right ?
> >
> 
> Yes.

OK but as you clarified in other e-mail then the attribute is added but
its just empty. This is rather ambiguous -- lets instead try to not add
the attribute if one is not available.

> And there are some drivers which have duplicate values in the hash.
> foo.o -> CONFIG_FOO CONFIG_FOO

What is the reason for this ?

> Although this one has one match it's filtered as having 2 CONFIGs.
> 
> >> The result of this patchset is the following. All modules from
> >> /sys expose the correct CONFIG_* symbol in the module attribute
> >> kconfig_symb with some exceptions. For a total number of 58
> >> modules,
> >
> > What kernel configuration did you use ? What architecture ?
> > If you use allmodconfig, what do the numbers look like ?
> >
> 
> I have a virtual machine in which I created the configuration with
> make localmodconfig and installed the new kernel.
> $  uname -a
> Linux ubuntu 4.7.0+ #28 SMP Mon Aug 15 20:39:19 CEST 2016 x86_64
> x86_64 x86_64 GNU/Linux
> 
> Should I send you the .config file ?

This is not needed, I ran your patches through 0-day and it was happy.
Good job !

  Luis

[toc] | [prev] | [next] | [standalone]

#1469930

FromChristoph Hellwig <hch@lst.de>
Date2016-08-25 09:50 +0200
Message-ID<s9XAd-6uu-25@gated-at.bofh.it>
In reply to#1465889
The idea seems useful, but I reallt don't like the 'reverse-engineering'
approach.

If we want to this properly from the ground up we should just split out
our CONFIG_ SYMBOLS into

MODULE_* - builds exactly one module (tristate, or maybe also as a built-in
only one, then like a bool)

CONFIG_* - just bool, MODULE_ may depend on it, too.

The other nice thing is that we could probably fold most of the Makefiles
into Kconfig using that methods as well, by listing the objectes required
for a module, e.g.

module NVME_TARGET
	tristate "NVMe Target support"
	depends on BLOCK
	depends on CONFIGFS_FS
	name nvmet
	objects core.o configfs.o admin-cmd.o io-cmd.o fabrics-cmd.o
	objects discovery.o

module NVME_TARGET_LOOP
	tristate "NVMe loopback device support"
	depends on BLK_DEV_NVME
	depends on NVME_TARGET
	select NVME_FABRICS
	select SG_POOL
	name nvme-loop
	objects loop.o

[toc] | [prev] | [next] | [standalone]

#1469967

FromJohannes Berg <johannes@sipsolutions.net>
Date2016-08-25 10:40 +0200
Message-ID<s9YmB-71V-7@gated-at.bofh.it>
In reply to#1469930
> The other nice thing is that we could probably fold most of the
> Makefiles into Kconfig using that methods as well, by listing the
> objectes required for a module, e.g.
> 
> module NVME_TARGET
> 	tristate "NVMe Target support"
> 	depends on BLOCK
> 	depends on CONFIGFS_FS
> 	name nvmet
> 	objects core.o configfs.o admin-cmd.o io-cmd.o fabrics-cmd.o
> 	objects discovery.o
> 

If this was going to be a thing, then you might also have

config NVME_TARGET_FOO
	bool "NVMe target supports FOO"
	module NVME_TARGET
	objects foo.o

The "module" would be like a "depends on" plus giving the module for
generating the Makefile, and now you can really remove most Makefile
stuff... :)

johannes

[toc] | [prev] | [next] | [standalone]

#1470365

From"Luis R. Rodriguez" <mcgrof@kernel.org>
Date2016-08-25 22:00 +0200
Message-ID<sa8YG-5nC-29@gated-at.bofh.it>
In reply to#1469967
On Thu, Aug 25, 2016 at 10:00:20AM +0200, Johannes Berg wrote:
> 
> > The other nice thing is that we could probably fold most of the
> > Makefiles into Kconfig using that methods as well, by listing the
> > objectes required for a module, e.g.
> > 
> > module NVME_TARGET
> > 	tristate "NVMe Target support"
> > 	depends on BLOCK
> > 	depends on CONFIGFS_FS
> > 	name nvmet
> > 	objects core.o configfs.o admin-cmd.o io-cmd.o fabrics-cmd.o
> > 	objects discovery.o
> > 
> 
> If this was going to be a thing, then you might also have
> 
> config NVME_TARGET_FOO
> 	bool "NVMe target supports FOO"
> 	module NVME_TARGET
> 	objects foo.o

You mean this instead of a Makefile:

foo-$(CONFIG_NVME_TARGET_FOO) += foo.o

?

> The "module" would be like a "depends on" plus giving the module for
> generating the Makefile, and now you can really remove most Makefile
> stuff... :)

  Luis

[toc] | [prev] | [next] | [standalone]

#1469981

FromMichal Marek <mmarek@suse.com>
Date2016-08-25 10:50 +0200
Message-ID<s9Ywi-75h-37@gated-at.bofh.it>
In reply to#1469930
On 2016-08-25 09:43, Christoph Hellwig wrote:
> The idea seems useful, but I reallt don't like the 'reverse-engineering'
> approach.
> 
> If we want to this properly from the ground up we should just split out
> our CONFIG_ SYMBOLS into
> 
> MODULE_* - builds exactly one module (tristate, or maybe also as a built-in
> only one, then like a bool)
> 
> CONFIG_* - just bool, MODULE_ may depend on it, too.
> 
> The other nice thing is that we could probably fold most of the Makefiles
> into Kconfig using that methods as well, by listing the objectes required
> for a module, e.g.
> 
> module NVME_TARGET
> 	tristate "NVMe Target support"
> 	depends on BLOCK
> 	depends on CONFIGFS_FS
> 	name nvmet
> 	objects core.o configfs.o admin-cmd.o io-cmd.o fabrics-cmd.o
> 	objects discovery.o
> 
> module NVME_TARGET_LOOP
> 	tristate "NVMe loopback device support"
> 	depends on BLK_DEV_NVME
> 	depends on NVME_TARGET
> 	select NVME_FABRICS
> 	select SG_POOL
> 	name nvme-loop
> 	objects loop.o

It looks nice for the simple case, but as soon as you need something
non-standard, you will need to mix a kconfig generated and a manually
written Makefile snippet.

Michal

[toc] | [prev] | [next] | [standalone]

#1470402

From"Luis R. Rodriguez" <mcgrof@kernel.org>
Date2016-08-25 22:40 +0200
Message-ID<sa9Bn-5Uq-13@gated-at.bofh.it>
In reply to#1469930
On Thu, Aug 25, 2016 at 09:43:13AM +0200, Christoph Hellwig wrote:
> The idea seems useful, but I reallt don't like the 'reverse-engineering'
> approach.
> 
> If we want to this properly from the ground up we should just split out
> our CONFIG_ SYMBOLS into
> 
> MODULE_* - builds exactly one module (tristate, or maybe also as a built-in
> only one, then like a bool)
> 
> CONFIG_* - just bool, MODULE_ may depend on it, too.

Curious what does the split buy us if the real meaningful input is the value
assigned to the config ? Ie, MODULE_FOO=m would be the modules we want to
check for.

> The other nice thing is that we could probably fold most of the Makefiles
> into Kconfig using that methods as well, by listing the objectes required
> for a module, e.g.

OK If the Kconfig file has the objects listed I can see the gain of using
Kconfig then to more easily map out to a symbol, given doing this on Makefiles
is not straight forward.

> module NVME_TARGET
> 	tristate "NVMe Target support"
> 	depends on BLOCK
> 	depends on CONFIGFS_FS
> 	name nvmet
> 	objects core.o configfs.o admin-cmd.o io-cmd.o fabrics-cmd.o
> 	objects discovery.o
> 
> module NVME_TARGET_LOOP
> 	tristate "NVMe loopback device support"
> 	depends on BLK_DEV_NVME
> 	depends on NVME_TARGET
> 	select NVME_FABRICS
> 	select SG_POOL
> 	name nvme-loop
> 	objects loop.o

I can see a huge win of having a direct specification that provides as a
feature two way mapping from CONFIG <--> module (objects) and backwards again
easily and clearly without hacks, specially if upon boot then we can then
provide the precise kernel configuration you need, for both built-in and
modules. The above could help with modules -- for built-in reverse mapping
we'd need something else, perhaps a configurable option to keep tabs on
inits called with associated configs.

The above would be a pretty intrusive change though, in comparison to
Cristina's original approach. The reverse-engineering object --> config
aspect of her work and of the old scripts/kconfig/streamline_config.pl
explains why it was hard. I'd be curious to learn of other gains possible
other than those listed so far, if we had this.

Re-iterating gains of having a simple two way CONFIG <--> module (objects)
mapping (following the above proposal now):

a) When optimizing build requirements for a kernel for a system.                                                                                                           
   That is you boot into a distro kernel and then want to build                                                                                                            
   a slim kernel only with sensible kernel configuration options.                                                                                                          

b) When you are on a distribution kernel but the distribution                                                                                                              
   kernel provided lacks hardware support for your device, you                                                                                                             
   may either want to upgrade the full kernel in which case you                                                                                                            
   want to do a) or -- you may want to just a backports release                                                                                                            
   which provides just the modules you need, you'd use it on top                                                                                                           
   of the distribution kernel.                                                                                                                                             

c) Having the mapping in sysfs would allow to simplify                                                                                                                       
   streamline_config.pl avoid parsing Makefiles in perl. (From Michal)

d) Fold most of the Makefiles into Kconfig

In retrospect c) still seems related to a) as we'd do away with
the hacks completely needed by streamline_config.pl, a) can be
augmented if we figure out a built-in solution as well.

d) Just seems like collateral of a more precise mapping than
what a Makefile provides. Anything else ?

  Luis

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web