Please merge procfs... :-)

[David Zeuthen]

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.

> 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.

> Also we have to consider the fact that some keys can be updated by
> polling, by an event, or by both.
> The polling interval could/should be part of a user policy, so we can
> change it dynamically.
> 

Not sure; this sounds like an uninteresting implementation detail
cf. my rant above about 'idealized interface'. 

> 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.

Thanks,
David


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