Re: [PATCH] hwmon/sensors: fix SENSORS_LM75 dependencies

[Eduardo Valentin <eduardo.valentin@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

On 07-01-2014 11:07, Jean Delvare wrote:
> On Tue, 7 Jan 2014 10:57:52 -0400, Eduardo Valentin wrote:
>> On 07-01-2014 10:05, Zhang, Rui wrote:
>>> BTW, I've been thinking of make CONFIG_THERMAL a bool since long time ago, the only thing that blocks me is that Thermal subsystem needs to register a hwmon device for each thermal zone and CONFIG_HWMON is a tristate.
>>
>> I agree with the move of having CONFIG_THERMAL as bool. Unless you have
>> use cases where users are dynamically loading and unloading thermal per
>> user demand, which I doubt.
> 
> Modularity is not only about reloading modules (although this can be
> useful for developers in particular.) It's also about enabling many
> features in a generic distribution kernel and each feature only gets
> loaded/used on the hardware which needs it. This is why, as a

In fact, no one has said anything different than the above. I definitely
agree with you. Except that this needs to be taken with a bit of care.

> distribution kernel maintainer, I keep complaining when I see boolean
> options which might easily be tristates.

Well, I would say it is not that 'easy' and not that straight forward.
there a couple of items to be considered in the thermal case, the boot
requirements and API provisioning are two, just to mention. There are
use cases that waiting for init to be loaded and modules to be linked is
just no go for thermal constraints, in case the system is already booted
'hot'.

Besides, hiding APIs when a component is build is module is not very
'modular', even considering the statements you brought above.

> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]