RFC: MK_BLOBS build option

[Robert Millan]

El 23 de gener de 2012 19:57, Xin Li <delphij at delphij.net> ha escrit:
> Please note that it's still possible to compile these into kernel if
> they present in the kernel compile configuration (for instance, device
> hptmv), which sounds a little bit non-intuitive to me.  Maybe we
> should create three include file (BLOBS, BLOBS_HOST, BLOBS_UCODE
> perhaps) that lists these modules as 'nodevice <device name>' in the
> same time, so they can be included from a kernel configuration file at
> the end?

Sounds useful, but I'm not sure how would one implement this so that
it is maintainable and doesn't break.

First when you create a file to disable ucode-blobs, you have to
enumerate the drivers again, creating redundancy (which usually leads
to bitrot).

Then when you create a file that disables both ucode-blobs and
host-blobs, you either enumerate the drivers over again, adding a
second level of redundancy, or have to use "include" directive. But
you can't just include both ucode-blob and host-blob files because
they both include GENERIC, and then GENERIC would be included twice,
right?

The idea sounds great (in my case it'd allow me to reduce our delta a
bit further), but in practice I'm not sure this can work.