Re: [alsa-devel] [GIT PULL] sound updates for 4.15-rc1
On Wed, Nov 15, 2017 at 8:19 AM, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:
The bucketization you are talking about is already implemented in practice, when you select the SOC options you have a set of machine drivers that show up in the menu options.
So what the network drivers do - because they have an absolutely sh*tload of drivers - is to have vendor-specific helper "gatekeeping" options that do not affect the code in *any* way, but only affect the config option dependencies for that vendor.
And those gatekeeping options are then "default y", so that when you add a new gatekeeper, you do not limit people by default - but you also don't add any actual code to the kernel!
So for example, you'll see things like this:
config NET_VENDOR_ADAPTEC bool "Adaptec devices" default y depends on PCI
if NET_VENDOR_ADAPTEC
... all the ADAPTEC network driver configs go here, ... even if right now there's only one
endif # NET_VENDOR_ADAPTEC
and note how CONFIG_NET_VENDOR_ADAPTEC does not show up in the source AT ALL, except as a "ok, the make recurses into the adapted subdirectory".
So NET_VENDOR_ADAPTEC is purely used to make the configuration choice easy. Instead of seeing a million different network driver questions, you see a hundred different network driver _vendor_ choices, and then only if you enable a vendor will you see the individual drivers.
So by default, all vendors are enabled, so "make oldconfig" etc works fine, but if you are a human that goes through things by hand, you can just say 'n' to the vendor, and not have to say 'n' to the fifteen different (or sometimes just one - the ADAPTEC example really was a bad choice) individual drivers.
That actually works quite well. And exactly because there is no actual code that gets enabled by these vendor choices, they can be enabled by default, so that when you add a new vendor gatekeeper and move an old config option to depend on that vendor, it doesn't affect "make oldconfig" negatively.
(Networking didn't always do this, but they've been pretty consistent about it the last many years - exactly because networking used to be a nightmare just because there are _so_ many different random network cards).
Linus
participants (1)
-
Linus Torvalds