[lkml]   [2013]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 01/03] clocksource: Add Kconfig entries for CMT, MTU2, TMU and STI
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.


 \ /
  Last update: 2013-11-13 23:01    [W:0.133 / U:12.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site