Re: Thermal kernel events API to userspace - Was: Re: thermal:Avoid CONFIG_NET compile dependency

[Henrique de Moraes Holschuh]

On Wed, 26 Jan 2011, Zhang, Rui wrote:
> > > I wonder which events would need userspace to take specific
> > > (configured) actions at all and what kind of action it could be.
> > 
> > All of them can have sensible generic actions.  See my other email.
> > 
> > > What is THERMAL_USER_AUX0?
> > > When will it get thrown and what is userspace expected to do?
> > 
> > Good question.  What use are those "user defined" events in a generic
> > interface, anyway?  You will have to know exactly what device is
> > issuing the
> > "generic user defined" event, and what it means for that device.
> > 
> > When you need a device-specific interface, you design one that is well
> > defined, such as thinkpad-acpi's thinkpad-specific "acpi" events.  If
> > you
> > get any thinkpad-acpi specific event, you know exactly what it is, and
> > nothing else ever issues those events, so you will never get them from
> > somewhere else with a different meaning.
> >
> I think you are talking about something like this:
> enum events {
> 	/* generic thermal event */
> 	THERMAL_WARN,
> 	THERMAL_EMERG,
> 	THERMAL_CRIT,
> 	/* coretemp thermal events */
> 	TEHRMAL_CT_AUX0,
> 	TEHRMAL_CT_AUX1,
> 	/* Thinkpad battery thermal events */
> 	THERMAL_TP_BAT_CRIT,
> 	THERMAL_TP_BAT_EMERG,
> 	THERMAL_DEV_FAULT,
> };
> Right?

Hmm, no.  I already perfectly fine, strictly defined driver-specific events.
And driver-specific events are useless crap in practice.  Nobody really
codes userspace utilities for them.  Maybe some 10-20 power users write ACPI
rules and scripts to deal with them, but that's it.

I am quite willing and happy to keep the driver-specific events for those 20
people in the world that actually used them to make something nice, and even
add new ones when necessary.  But that is NOT the way to go forward when
you have any sort of choice.

I.e.  I'd like THERMAL_BAT_CRIT, THERMAL_BAT_EMERG, and a strict enough
definition of what they mean, that userspace (or a kernel thermal event
handler) could process them and do the right thing regardless of which
driver generated the events, because it would be sure of what they mean.

You might want to change that to a two-axis or three-axis event, actually:

What:   THERMAL_NORMAL, THERMAL_WARN, THERMAL_EMERG, THERMAL_CRIT,
        THERMAL_SENSOR_FAULT...

Where:  SYSTEM (aka: unknown/generic), BATTERY, CPU, GPU, PSU, PCIDEV, USBDEV...

Extended code: (what,where)-specific.  For example, could be the specific
core or package for (*, CPU) events...

BTW: thermal_normal means "alarm condition cleared".  Like thermal_warn, I
wouldn't expect every device to be able to raise it.  Thinkpads, for
example, won't tell you when they're back to normal operating conditions
AFAIK.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/