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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5283EBCD.9050007@linaro.org>
Date:	Wed, 13 Nov 2013 22:14:53 +0100
From:	Daniel Lezcano <daniel.lezcano@...aro.org>
To:	John Stultz <john.stultz@...aro.org>,
	Magnus Damm <magnus.damm@...il.com>
CC:	linux-kernel <linux-kernel@...r.kernel.org>,
	Kevin Hilman <khilman@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	SH-Linux <linux-sh@...r.kernel.org>,
	"Simon Horman [Horms]" <horms@...ge.net.au>,
	Olof Johansson <olof@...om.net>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 01/03] clocksource: Add Kconfig entries for CMT, MTU2,
 TMU and STI

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/