Please merge procfs... <img alt=":-)" src="http://news.gmane.org/img/smilies/smile.png"

[Richard Hughes]

David Zeuthen <david <at> fubar.dk> writes:
> 
> On Sat, 2005-01-29 at 19:30 +0200, Paul Ionescu wrote:
> > For some sensors we can use something like acpid to get notified when we
> > need to refresh a value. For instance, AC adapter sends an ACPI event when
> > state changes.
> >  
> I don't want a dependency on acpid, we should just read things off
> the /proc/acpi/event socket.

Sure, that means disabling acpid and ignoring /etc/acpi/actions/ and
/etc/acpi/events/, although I admit I have nothing in either.

Although I agree, I don't like the double query approach.

Can we use some sort of kernel hook (FAM?) to the file /proc/acpi/events? 
How does acpid do it, or does it poll?
 
> > Also we may want to implement something like "client side initiation",
> > meaning that for some sensors, the client can ask for a hal key, and then
> > we read that key (value) in that moment, and update the value.
> > So, if a battery applet asks for the battery level, we can read the level
> > when it asks for it.
> > This will be of use if the general policy is "refresh these keys every X
> > minutes", but then if an application asks for a specific key, we
> > actually read that key upon request.
> > 
> 
> No, the information contained in hal shouldn't depend on whether
> someone reads it. The point is really that e.g. desktop applications
> waits for a notification from hal when something changes. E.g. hal
> provides an idealized interface though we may need to do polling and
> whatnot in the hal daemon.

Agree, the onus is on HAL providing the information, not the application
requesting it.

> > On my IBM T41, I have a fan which is not described as a standard acpi fan,
> > but it exist and I can get it's RPM value from ibm-acpi module
> > (/proc/acpi/ibm/somefile ). IMO, the right thing to do, is to hide this to
> > users, and expose it as a regular fan. What do you think about it ?
> > If you prefer, I can expose it as system.something.ibm.fan_speed or
> > something, but I think that this is not the right thing.
> > 
> 
> We should definitely hide the detail that this is IBM specific, e.g. we
> should abstract it.

Already on the case, my toshiba has toshiba/fan which contains:
running:                 0
force_on:                0

Which I was going to use the generic fan interface and subclass it with
information from refresh_toshiba_extras.

The question is, do you have a /proc/acpi/fan/FAN0/ interface as well? 
I do. I seems to do nothing.

Richard.

_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal