Message-ID: <CAN43C+fnLSLgK-8cLrr-2Topme2LV+_Oy-KXFYZpLVDiA3-frQ@mail.gmail.com>
Date:   Wed, 24 Aug 2016 23:01:45 +0530
From:   Naveen Kumar <nk1383886@...il.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Michal Marek <mmarek@...e.com>,
        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

unsubscribe backports

On 8/24/16, Luis R. Rodriguez <mcgrof@...nel.org> wrote:
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe backports" in
>

Powered by blists - more mailing lists