[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cc2c4d65-aa57-a04d-8e2a-75c13943b2b7@suse.com>
Date: Thu, 25 Aug 2016 10:41:25 +0200
From: Michal Marek <mmarek@...e.com>
To: Christoph Hellwig <hch@....de>,
"Luis R. Rodriguez" <mcgrof@...nel.org>
Cc: 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>,
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 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
Powered by blists - more mailing lists