Re: Generic battery interface

[Greg KH]

On Fri, Jul 28, 2006 at 01:56:03AM +0300, Shem Multinymous wrote:
> On 7/28/06, Pavel Machek <pavel@xxxxxxx> wrote:
> >+ perhaps it would not need explicit maintainer, just assign names
> >        carefully
> 
> We also need to decide on clear convention about units. Are they in
> the output and/or filename? Filename is best, I think, since it's
> impossible to miss and works nicely for input attributes too.

Actually, this whole thing could probably just go under the 'hwmon'
interface, as it already handles other hardware monitoring events.  I
don't see how a battery would be any different, do you?

> >- does not suit PC-style batteries which trigger events when data
> >        change (can be fixed by /sys/XXX/anything-new, which gives one
> >        byte when something changes)
> 
> Changed since last poll? That doesn't work with multiple clients.
> Changed for the last X seconds? That requires everybody to poll that
> frequenty, and risks missing events due to system load.

Again, look at the hwmon documentation, they handle alarms and other
things already that you are trying to re-invent.

> Wild thought: how about adding a generic "event source" mechanism into
> sysfs, at the same level as attributes? Maybe even make them textual,
> in keeping with sysfs philosophy:
> 
> while read TYPE PARAM  < /sys/class/battery/BAT0/criticl_events; do
>  echo "battery 0 generated ctitical event $TYPE with parameters $PARAM"
> done

Heh, no, the file should specify the units, and then you document it.
Much simpler.

> The simpler solution is to convert events into state (e.g.,
> critical=0/1) and present them as normal attributes which userspace
> can poll, as Greg KH suggested (did I get that right?).

Yes, just like temperature events today.

People have asked for the "this sysfs file's value changed" type uevent
message to come back, so that's also an option that might be used here.

thanks,

greg k-h
-
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/