Message-ID: <20160824163333.GR3296@wotan.suse.de>
Date:   Wed, 24 Aug 2016 18:33:33 +0200
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Michal Marek <mmarek@...e.com>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Cristina Moraru <cristina.moraru09@...il.com>,
        "vegard.nossum@...il.com" <vegard.nossum@...il.com>,
        Valentin Rothberg <valentinrothberg@...il.com>,
        Hannes Reinecke <hare@...e.de>,
        Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org,
        teg@...m.no, kay@...y.org, rusty@...tcorp.com.au,
        akpm@...ux-foundation.org, backports@...r.kernel.org,
        Guenter Roeck <linux@...ck-us.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "rafael.j.wysocki" <rafael.j.wysocki@...el.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Takashi Iwai <tiwai@...e.de>, Christoph Hellwig <hch@....de>,
        Mauro Carvalho Chehab <mchehab@....samsung.com>,
        Johannes Berg <johannes@...solutions.net>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Paul Bolle <pebolle@...cali.nl>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Alexey Khoroshilov <khoroshilov@...ras.ru>,
        Sathya Prakash Veerichetty <sathya.prakash@...adcom.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Laurence Oberman <loberman@...hat.com>,
        Johannes Thumshirn <jthumshirn@...e.de>,
        Tejun Heo <tj@...nel.org>,
        Jej B <James.Bottomley@...senpartnership.com>,
        Theodore Ts'o <tytso@....edu>, danijons@...dent.chalmers.se,
        Andrzej Wasowski <wasowski@....dk>
Subject: Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute

On Wed, Aug 24, 2016 at 01:05:04PM +0200, Michal Marek wrote:
> On 2016-08-23 23:32, Luis R. Rodriguez wrote:
> > On Fri, Aug 19, 2016 at 11:07:36AM +0200, Michal Marek wrote:
> >> On 2016-08-18 19:55, Luis R. Rodriguez wrote:
> >>> 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.
> >>
> >> c) Having the mapping in sysfs would allow to simplify
> >> streamline_config.pl avoid parsing Makefiles in perl.
> > 
> > Indeed, this was actually a side possible goal here :) only it seems
> > we totally forgot about it while addressing the work.
> > 
> >> Only if the patch did not depend on streamline_config.pl :)
> > 
> > Indeed, lets get rid of that dependency.
> > 
> >> One idea would be to generate
> >> the Module.ksymb in a similar way we generate the modules.builtin file:
> >> Generate an alternate include/config/*.conf with all CONFIG_FOO=m
> >> replaced with
> >>
> >> CONFIG_FOO=m-CONFIG_FOO
> >>
> >> and in the Makefile, iterate over $(filter m-CONFIG_%, $(.VARIABLES)) to
>                                        should be obj-m-CONFIG_%
> 
> >> create the mapping. This would also properly cover cases where we build
> >> the $(obj-m) list from another list. It would certainly create other
> >> corner cases, but it's worth trying IMO.
> > 
> > Neat, would that cover lib-m then as well or other targets that would generate 
> > modules ?
> 
> This would have to be handled as well by the patch. Obviously it's not
> going to be as simple as described in a single paragraph of text :).

Ah OK, it was not clear to me if your suggestion captured all modules already.
There may still be a way. We just have to look harder. Then what precise
target was used would be irrelevant.

> >> Another thing is that we do not necessarily need to record this
> >> information in .modinfo, but we can generate a list in
> >> /lib/modules/`uname -r`/ for consumption. It could also include drivers
> >> that are builtin in the current configuration.
> > 
> > Well so one future use would be for instance a 'make udevconfig' which
> > in theory should be able then to scrape all possible related needed
> > device CONFIG_'s and then give you an optimal kernel configuration.
> > It'd be nice to be able to extract this from the kernel and modules
> > without needing build sources in /lib/modules/`uname -r`/.
> 
> I meant that the file can be installed by modules_install. Like you have
> /lib/modules/`uname -r`/modules.builtin with recent kernels and recent
> distro packages.

Got it.

> But really, it's a minor issue how the information is
> presented to userspace.

To us perhaps, but to userspace and users this is a big deal. It'd be nice
to be able to construct a kernel config only with what CONFIG's your hardware
needs, doing this should mean trying to expose enough information in a way
userspace is easily able to handle. The reason to go with the mod section stuff
was this was already being picked up by udevadm for its own hardware db info,
so this seemed like a logical evolution, and it would not require your
kernel sources installed.

  Luis

Powered by blists - more mailing lists