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 -- To unsubscribe from this list: send the line "unsubscribe backports" in
