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:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
