Thermal Zones

[David Zeuthen]

On Sun, 2006-11-26 at 16:49 +0000, Richard Hughes wrote:
> On Sun, 2006-11-05 at 21:11 -0500, Stu Hood wrote:
> > You're right, this needs to be partitioned more. I still think the
> > thermal_zone capability is a good idea, but the temperature data could
> > be made more useful if it was placed into the 'sensor' namespace. That
> > way, systems with ACPI could have an abstract thermal_zone device in
> > HAL with the capabilities 'thermal_zone' and 'sensor', and systems
> > without ACPI could still expose temperature data for physical devices
> > with the 'sensor' namespace. 
> > 
> > I've posted v2 of the spec... which moves the temperature data into
> > the 'sensor' namespace so that it can be more generally useful.
> > 
> > http://www.hoodidge.net/development/thermal_zone_v2.html
> 
> The sensor stuff looks great and ready to commit IMO. 

Have you looked at the new kernel lm_sensors code? I haven't done this
myself but before we commit to an interface for HAL we really need to
understand what the hardware and/or kernel is capable of giving us.
Perhaps their user space library is even the right approach for desktop
apps; I mean, is having sensors / thermal zones etc. useful to have in
HAL apart from powering a UI gizmo?

I'm also not convinced that sensor.* as an abstract name space is that
useful; for the record we already have light_sensor.*, perhaps that
level of abstraction is better... e.g. we'd have

 light_sensor
 temperature_sensor
 ... and so on

I'm also unconvinced that sensor.reporting.current is the right
approach. For the light sensor stuff the interface is poll-based, e.g.
g-p-m actually polls the light sensor, through HAL method calls, and I
think that is fine.. Because.. I think.. What I'm trying to say... I'd
hate to have a bunch of processes in hal sitting and polling only to be
ready if someone launches a UI gizmo that displays the fan RPM and
motherboard temperature etc.

     David