[alsa-devel] [GIT PULL] sound updates for 4.15-rc1

[Linus Torvalds]

On Wed, Nov 15, 2017 at 8:19 AM, Pierre-Louis Bossart
<pierre-louis.bossart at 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