Hardware dependencies in Kconfig
From: Jean Delvare
Date: Mon Apr 14 2014 - 08:54:21 EST
Configuring kernels from scratch has become an incredibly long and
tedious task. The reason is that the number of drivers and options has
exploded in the past few years. Which in itself is great - Linux is
successful, yeah! - but the side effects must be dealt with.
6000-line .config files are no fun.
Earlier today, I found that NET_CADENCE is set in my x86-64 kernel
configuration. The two ethernet drivers below this menu are for ARM
machines. I really shouldn't be asked about that on x86-64. I just sent
a patch addressing this specific issue, which follows about 50 similar
patches from me for similar issues in various subsystems. But I can't
do all of that by myself, this is too much work quantitatively, and I
am not always the best person to find out the proper hardware
dependencies that should be added.
I would like to call for proper hardware dependencies to become a
general trend: every new hardware-specific driver which is added to the
kernel should depend on ($hardware || COMPILE_TEST), so as to make it
clear right away, which type of hardware is expected to need the driver
$hardware can be the top-level architecture (e.g. ARM), but can also go
down to sub-architecture/platform (e.g. ARCH_AT91 or PLATFORM_AT32AP) or
even machine (e.g. PICOXCELL_PC3X3). The list can always be extended
later if needed. Ideally we should restrict as much as possible as long
as the result is easy to maintain, not too complex, and not likely to
break in a near future.
Thanks to COMPILE_TEST, we don't lose the build test coverage, and it
also makes it possible for anyone to still build the driver if the
dependency is too strict (as a temporary workaround until it gets fixed
upstream, that is.)
Does anyone object to this?
Ideally existing drivers would get the same treatment, and I encourage
subsystem maintainers or architecture maintainers to check which of
"their" drivers would benefit from that. But I understand this will take
some time, and this is certainly harder for existing drivers as a risk
of regression exists if we set too strict dependencies.
SUSE L3 Support
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/