[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160825074313.GC18622@lst.de>
Date: Thu, 25 Aug 2016 09:43:13 +0200
From: Christoph Hellwig <hch@....de>
To: "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>,
Michal Marek <mmarek@...e.com>, 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
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
Powered by blists - more mailing lists