Please merge procfs... :-)

[Paul Ionescu]

Hi Richard,

On Sat, 29 Jan 2005 16:22:05 +0000, Richard Hughes wrote:

> Okay, I've merged all my procfs files into a copy of cvs head.
> 
> Put simply it's the foundation work - the values are not refreshed, i.e.
> the battery and ac_adaptor do not change yet, but are correct on
> initialisation. The refresh code is pretty trivial, but we need to talk
> more about polling and events first. Plus PMU doesn't do much yet, but the
> framework is in place.
> 

Nice work.
Here are some more ideas:

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.

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.

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.

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.

Thanks,
Paul


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