Re: [PATCH v2 01/03] clocksource: Add Kconfig entries for CMT, MTU2, TMU and STI

[John Stultz <john.stultz@linaro.org>]

On 11/13/2013 01:14 PM, Daniel Lezcano wrote:
> 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.

This one I'm not sure I agree with completely. Basically I think
exceptions are reasonable, but we ought to keep the bar fairly high for
adding a user-visible config option.


> 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).

Again, the main point for me is I don't even want the options to be
visible unless there is a real need. There may be reasonable exceptions,
but for the most part we shouldn't see these.

I'll go back to Magnus' original mail and reply with the sort of
questions I think we should answer before adding user visible configs.

thanks
-john