From: "Luis R. Rodriguez" <mcgrof@kernel.org> To: Christoph Hellwig <hch@lst.de> Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>, 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>, Michal Marek <mmarek@suse.com>, 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>, 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: Thu, 25 Aug 2016 22:19:19 +0200 [thread overview] Message-ID: <20160825201919.GE3296@wotan.suse.de> (raw) In-Reply-To: <20160825074313.GC18622@lst.de> 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 -- To unsubscribe from this list: send the line "unsubscribe backports" in
WARNING: multiple messages have this Message-ID (diff)
From: "Luis R. Rodriguez" <mcgrof@kernel.org> To: Christoph Hellwig <hch@lst.de> Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>, 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>, Michal Marek <mmarek@suse.com>, 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>, 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: Thu, 25 Aug 2016 22:19:19 +0200 [thread overview] Message-ID: <20160825201919.GE3296@wotan.suse.de> (raw) In-Reply-To: <20160825074313.GC18622@lst.de> 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
next prev parent reply other threads:[~2016-08-25 20:53 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-17 19:26 [RFC PATCH 0/5] Add CONFIG symbol as module attribute Cristina Moraru 2016-08-17 19:26 ` [RFC PATCH 1/5] Add generation of Module.symb in streamline_config Cristina Moraru 2016-08-18 18:22 ` Luis R. Rodriguez 2016-08-18 18:22 ` Luis R. Rodriguez 2016-08-18 18:32 ` 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-20 14:49 ` Cristina-Gabriela Moraru 2016-08-23 19:00 ` Luis R. Rodriguez 2016-08-23 19:00 ` Luis R. Rodriguez 2016-08-17 19:27 ` [RFC PATCH 2/5] Add CONFIG symbol to module as compilation parameter Cristina Moraru 2016-08-18 18:10 ` Luis R. Rodriguez 2016-08-18 18:10 ` Luis R. Rodriguez 2016-08-18 18:55 ` Luis R. Rodriguez 2016-08-18 18:55 ` Luis R. Rodriguez 2016-08-20 15:11 ` Cristina-Gabriela Moraru 2016-08-20 15:11 ` Cristina-Gabriela Moraru 2016-08-23 19:07 ` Luis R. Rodriguez 2016-08-23 19:07 ` Luis R. Rodriguez 2016-08-17 19:27 ` [RFC PATCH 3/5] Trigger Module.ksymb generation in Makefile Cristina Moraru 2016-08-18 18:30 ` Luis R. Rodriguez 2016-08-18 18:30 ` Luis R. Rodriguez 2016-08-17 19:27 ` [RFC PATCH 4/5] Set KCONFIG_KSYMB as value for kconfig_ksymb module attribute Cristina Moraru 2016-08-18 18:59 ` Luis R. Rodriguez 2016-08-18 18:59 ` Luis R. Rodriguez 2016-08-20 15:16 ` Cristina-Gabriela Moraru 2016-08-20 15:16 ` Cristina-Gabriela Moraru 2016-08-23 19:10 ` Luis R. Rodriguez 2016-08-23 19:10 ` Luis R. Rodriguez 2016-08-17 19:27 ` [RFC PATCH 5/5] Add kconf_symb as kernel " Cristina Moraru 2016-08-18 19:02 ` Luis R. Rodriguez 2016-08-18 19:02 ` Luis R. Rodriguez 2016-08-18 17:55 ` [RFC PATCH 0/5] Add CONFIG symbol as " Luis R. Rodriguez 2016-08-18 17:55 ` Luis R. Rodriguez 2016-08-19 9:07 ` Michal Marek 2016-08-19 9:07 ` Michal Marek 2016-08-22 19:48 ` Cristina-Gabriela Moraru 2016-08-22 19:48 ` Cristina-Gabriela Moraru 2016-08-23 21:32 ` Luis R. Rodriguez 2016-08-23 21:32 ` Luis R. Rodriguez 2016-08-24 11:05 ` Michal Marek 2016-08-24 11:05 ` Michal Marek 2016-08-24 16:33 ` Luis R. Rodriguez 2016-08-24 16:33 ` Luis R. Rodriguez 2016-08-24 17:31 ` Naveen Kumar 2016-08-24 17:31 ` Naveen Kumar 2016-08-22 19:35 ` Cristina-Gabriela Moraru 2016-08-22 19:35 ` Cristina-Gabriela Moraru 2016-08-23 19:17 ` Luis R. Rodriguez 2016-08-23 19:17 ` Luis R. Rodriguez 2016-08-25 7:43 ` Christoph Hellwig 2016-08-25 7:43 ` Christoph Hellwig 2016-08-25 8:00 ` Johannes Berg 2016-08-25 8:00 ` Johannes Berg 2016-08-25 19:51 ` Luis R. Rodriguez 2016-08-25 19:51 ` Luis R. Rodriguez 2016-08-25 8:41 ` Michal Marek 2016-08-25 8:41 ` Michal Marek 2016-08-25 20:19 ` Luis R. Rodriguez [this message] 2016-08-25 20:19 ` Luis R. Rodriguez 2019-02-05 22:07 ` Luis Chamberlain 2019-02-05 22:07 ` Luis Chamberlain 2019-06-26 22:21 ` Luis Chamberlain 2019-06-26 22:21 ` Luis Chamberlain 2019-06-27 4:50 ` Christoph Hellwig 2019-06-27 4:50 ` Christoph Hellwig 2019-06-28 18:40 ` Luis Chamberlain 2019-06-28 18:40 ` Luis Chamberlain 2019-06-29 8:42 ` Greg Kroah-Hartman 2019-06-29 8:42 ` Greg Kroah-Hartman 2019-07-02 20:51 ` Luis Chamberlain 2019-07-02 20:51 ` Luis Chamberlain 2019-07-03 7:40 ` Greg Kroah-Hartman 2019-07-03 7:40 ` Greg Kroah-Hartman 2019-07-03 16:50 ` Luis Chamberlain 2019-07-03 16:50 ` Luis Chamberlain 2019-07-03 18:57 ` Greg Kroah-Hartman 2019-07-03 18:57 ` Greg Kroah-Hartman 2019-07-03 22:25 ` Luis Chamberlain 2019-07-03 22:25 ` Luis Chamberlain 2019-07-11 23:07 ` Brendan Higgins 2019-07-11 23:07 ` Brendan Higgins 2019-07-11 23:22 ` Luis Chamberlain 2019-07-11 23:22 ` Luis Chamberlain 2019-07-03 12:16 ` Enrico Weigelt, metux IT consult 2019-07-03 12:16 ` Enrico Weigelt, metux IT consult 2019-07-03 17:35 ` Luis Chamberlain 2019-07-03 17:35 ` Luis Chamberlain 2019-07-03 19:31 ` Enrico Weigelt, metux IT consult 2019-07-03 19:31 ` Enrico Weigelt, metux IT consult 2019-07-03 22:42 ` Luis Chamberlain 2019-07-03 22:42 ` Luis Chamberlain 2019-07-11 23:27 ` Brendan Higgins 2019-07-11 23:27 ` Brendan Higgins 2019-07-13 14:44 ` Enrico Weigelt, metux IT consult 2019-07-13 14:44 ` Enrico Weigelt, metux IT consult
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=20160825201919.GE3296@wotan.suse.de \ --to=mcgrof@kernel.org \ --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=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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.