From: Naveen Kumar <nk1383886@gmail.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Michal Marek <mmarek@suse.com>,
Cristina Moraru <cristina.moraru09@gmail.com>,
"vegard.nossum@gmail.com" <vegard.nossum@gmail.com>,
Valentin Rothberg <valentinrothberg@gmail.com>,
Hannes Reinecke <hare@suse.de>, Sam Ravnborg <sam@ravnborg.org>,
linux-kernel@vger.kernel.org, teg@jklm.no, kay@vrfy.org,
rusty@rustcorp.com.au, akpm@linux-foundation.org,
backports@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"rafael.j.wysocki" <rafael.j.wysocki@intel.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Takashi Iwai <tiwai@suse.de>, Christoph Hellwig <hch@lst.de>,
Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
Johannes Berg <johannes@sipsolutions.net>,
Hauke Mehrtens <hauke@hauke-m.de>,
Paul Bolle <pebolle@tiscali.nl>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Alexey Khoroshilov <khoroshilov@ispras.ru>,
Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Laurence Oberman <loberman@redhat.com>,
Johannes Thumshirn <jthumshirn@suse.de>,
Tejun Heo <tj@kernel.org>,
Jej B <James.Bottomley@hansenpartnership.com>,
"Theodore Ts'o" <tytso@mit.edu>,
danijons@student.chalmers.se, Andrzej Wasowski <wasowski@itu.dk>
Subject: Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute
Date: Wed, 24 Aug 2016 23:01:45 +0530 [thread overview]
Message-ID: <CAN43C+fnLSLgK-8cLrr-2Topme2LV+_Oy-KXFYZpLVDiA3-frQ@mail.gmail.com> (raw)
In-Reply-To: <20160824163333.GR3296@wotan.suse.de>
unsubscribe backports
On 8/24/16, Luis R. Rodriguez <mcgrof@kernel.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
>
--
To unsubscribe from this list: send the line "unsubscribe backports" in
next prev parent reply other threads:[~2016-08-24 17:31 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1471462023-119645-1-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 17:55 ` [RFC PATCH 0/5] Add CONFIG symbol as module attribute Luis R. Rodriguez
2016-08-19 9:07 ` Michal Marek
2016-08-22 19:48 ` Cristina-Gabriela Moraru
2016-08-23 21:32 ` Luis R. Rodriguez
2016-08-24 11:05 ` Michal Marek
2016-08-24 16:33 ` Luis R. Rodriguez
2016-08-24 17:31 ` Naveen Kumar [this message]
2016-08-22 19:35 ` Cristina-Gabriela Moraru
2016-08-23 19:17 ` Luis R. Rodriguez
2016-08-25 7:43 ` Christoph Hellwig
2016-08-25 8:00 ` Johannes Berg
2016-08-25 19:51 ` Luis R. Rodriguez
2016-08-25 8:41 ` Michal Marek
2016-08-25 20:19 ` Luis R. Rodriguez
2019-02-05 22:07 ` Luis Chamberlain
2019-06-26 22:21 ` Luis Chamberlain
2019-06-27 4:50 ` Christoph Hellwig
2019-06-28 18:40 ` Luis Chamberlain
2019-06-29 8:42 ` Greg Kroah-Hartman
2019-07-02 20:51 ` Luis Chamberlain
2019-07-03 7:40 ` Greg Kroah-Hartman
2019-07-03 16:50 ` Luis Chamberlain
2019-07-03 18:57 ` Greg Kroah-Hartman
2019-07-03 22:25 ` Luis Chamberlain
2019-07-11 23:07 ` Brendan Higgins
2019-07-11 23:22 ` Luis Chamberlain
2019-07-03 12:16 ` Enrico Weigelt, metux IT consult
2019-07-03 17:35 ` Luis Chamberlain
2019-07-03 19:31 ` Enrico Weigelt, metux IT consult
2019-07-03 22:42 ` Luis Chamberlain
2019-07-11 23:27 ` Brendan Higgins
2019-07-13 14:44 ` Enrico Weigelt, metux IT consult
[not found] ` <1471462023-119645-3-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 18:10 ` [RFC PATCH 2/5] Add CONFIG symbol to module as compilation parameter Luis R. Rodriguez
2016-08-18 18:55 ` Luis R. Rodriguez
2016-08-20 15:11 ` Cristina-Gabriela Moraru
2016-08-23 19:07 ` Luis R. Rodriguez
[not found] ` <1471462023-119645-2-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 18:22 ` [RFC PATCH 1/5] Add generation of Module.symb in streamline_config Luis R. Rodriguez
2016-08-18 18:32 ` Luis R. Rodriguez
[not found] ` <CAGZ2q2xi9Uy-ye387=mWhy_fOEJBC593Nos7fH027m-_ZdoOXA@mail.gmail.com>
2016-08-20 14:49 ` Cristina-Gabriela Moraru
2016-08-23 19:00 ` Luis R. Rodriguez
[not found] ` <1471462023-119645-4-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 18:30 ` [RFC PATCH 3/5] Trigger Module.ksymb generation in Makefile Luis R. Rodriguez
[not found] ` <1471462023-119645-5-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 18:59 ` [RFC PATCH 4/5] Set KCONFIG_KSYMB as value for kconfig_ksymb module attribute Luis R. Rodriguez
2016-08-20 15:16 ` Cristina-Gabriela Moraru
2016-08-23 19:10 ` Luis R. Rodriguez
[not found] ` <1471462023-119645-6-git-send-email-cristina.moraru09@gmail.com>
2016-08-18 19:02 ` [RFC PATCH 5/5] Add kconf_symb as kernel " Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAN43C+fnLSLgK-8cLrr-2Topme2LV+_Oy-KXFYZpLVDiA3-frQ@mail.gmail.com \
--to=nk1383886@gmail.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=backports@vger.kernel.org \
--cc=cristina.moraru09@gmail.com \
--cc=danijons@student.chalmers.se \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hare@suse.de \
--cc=hauke@hauke-m.de \
--cc=hch@lst.de \
--cc=johannes@sipsolutions.net \
--cc=jthumshirn@suse.de \
--cc=kay@vrfy.org \
--cc=khoroshilov@ispras.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=loberman@redhat.com \
--cc=martin.petersen@oracle.com \
--cc=mcgrof@kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=mmarek@suse.com \
--cc=paul.gortmaker@windriver.com \
--cc=pebolle@tiscali.nl \
--cc=rafael.j.wysocki@intel.com \
--cc=rusty@rustcorp.com.au \
--cc=sam@ravnborg.org \
--cc=sathya.prakash@broadcom.com \
--cc=teg@jklm.no \
--cc=tiwai@suse.de \
--cc=tj@kernel.org \
--cc=tytso@mit.edu \
--cc=valentinrothberg@gmail.com \
--cc=vegard.nossum@gmail.com \
--cc=wasowski@itu.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).