On 11/12/2013 09:47 PM, John Stultz wrote:
[ ... ]
I think all your goals make sense, and I would like to reach the same
place from a usability point of view. I would however like to allow
existing power users to select whatever they want enabled on their
platform. Ideally I also would like to share Kconfig bits between
multiple architectures where appropriate, but it's just a few lines of
code so I don't care that much.
And as long as the options for the power-users actually make sense,
that all sounds fine. But I want to make sure we aren't needlessly
causing pain to folks building kernels all to save a few lines of
Kconfig logic.
And again, this is just my pet peeve, I'm not the directory
submaintainer any more, so Daniel and Thomas are the ones to convince.
:)
So to summarize:
1. We want to prevent to manually select the drivers, this is painful to
have the right config. We assume the SoC config will choose the right
driver config option.
2. We want to disable some drivers because they could conflict. Or for
kernel builders, it is easier to hack around the options.
3. We want to select a driver as a module because the timer could reside
on a PCI board.
4. Code size could be an issue if everything is selected.
IMO, John's approach makes totally sense.
I am not worried about the code size because one day or another we will
have to fix up the code size increasing with the single zImage for ARM,
and we will probably end up to unload dynamically unneeded drivers from
the memory after booting (I don't how. Perhaps by some magic with the
init sections).
Disabling some drivers, or in other words, give more customization
options to the kernel builders, makes also sense.
It isn't possible to select the driver as we do right now but let them
optional from the Kconfig ? What if we invert the logic in the Kconfig,
make each driver depends on a arch_option defaulting to 'yes', so it can
be manually unselected (similar to drivers/cpuidle/Kconfig.arm).
In any case, consolidating SH and ARM Kconfig is ok but with a change
which is consistent with the current Kconfig, that is following the
policy of the Kconfig (on top of the current one or on top of a new one).
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/