Re: [lm-sensors] hwmon API update

[Jean Delvare <khali@linux-fr.org>]

On Mon, 14 Feb 2011 19:40:14 +0000, Matthew Garrett wrote:
> On Mon, Feb 14, 2011 at 11:33:55AM -0800, Guenter Roeck wrote:
> > On Mon, Feb 14, 2011 at 02:05:57PM -0500, Matthew Garrett wrote:
> > > The kernel has generic support for thermal management. Making it work 
> > > for any device is just a matter of a driver generating the appropriate 
> > > thermal and cooling devices and associating them. ACPI already works 
> > > this way.
> > > 
> > Not sure what you suggest here. Thermal devices register as hwmon devices
> > if so configured, so having hwmon devices register as thermal devices
> > would not work, at least not without some serious thought to prevent
> > registration loops.
> 
> That's really an implementation detail - the worst case at present is 
> that you'd end up with the same sensor providing data twice, but that's 
> fixable.

I agree. I tend to believe that this approach would be superior to the
initial proposal for the problem at hand. The few required hwmon
drivers would simply register their temperature sensors as thermal
zones, and their fan control outputs as cooling devices, to the thermal
subsystem. This requires no change to the hwmon core, nor to all other
individual hwmon drivers.

> > If you are looking for thermal device support, maybe the drivers in question 
> > should be implemented as thermal device drivers and provide hwmon functionality
> > through the thermal subsystem. Did you consider that option ?
> 
> We could definitely change the existing hwmon drivers to be thermal 
> drivers instead, but not everything they do fits into that model.

Not instead. Additionally.

> > Do you plan to use/utilize the thermal subsystem, or do you plan to duplicate
> > that functionality in the GPU driver(s) ? Guess that was one of the reasons
> > why Jean asked for a use case of the proposed API.
> 
> Use the thermal subsystem. That's why I made the ACPI thermal code 
> generic in the first place.

This sounds good.

> > If you plan to use the thermal subsystem without having to rewrite hwmon drivers,
> > did you consider means to interconnect the hwmon subsystem with the thermal subsystem,
> > eg by creating a means for hwmon devices to register as thermal devices ?
> 
> As I said, we could rework the hwmon drivers into thermal devices
> instead, but we'd still need a mechanism for providing the thermal 
> device back to the registering device.

Correct.

> > > Because hardware control is the kernel's job, not userspace's. Having 
> > > hardware melt just because userspace fell off a cliff isn't acceptable.
> > > 
> > The same argument would apply to system fan control, doesn't it ?
> 
> Yes, which is why it belongs in the kernel.

The truth is IMHO more complex than this. I tend to believe that fan
speed control (or more generally thermal management) can be implemented
at different levels. Think about it, it's just like CPU frequency
scaling. You have kernel governors and one user-space governor for
people unhappy about the in-kernel ones and/or for hardware which can't
be supported by these.

Ideally, thermal management would be implemented by the hardware, and
neither the kernel drivers nor user-space should have to care. Less
ideally, the kernel driver has to care, but has enough knowledge to do
this by itself without user intervention. The worse case is where the
kernel doesn't know and the user has to configure everything manually.
This is the case of many PC motherboards out there, for which users
rely on the user-space fancontrol script (or anything similar.) It can
be pretty useful, but I still avoid when I can. And I definitely
wouldn't recommend this approach for GPUs.

So I can envision a similarly layered thermal management logic, where
the kernel drivers take care of what they have to and can handle, and
leave the rest to user-space (as is already the case today.) In other
words, please let me be clear that I have no objection to what Matthew
and Martin are trying to achieve. My objections relate to the
implementation and the way to submit it for review.


-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors