Please merge procfs... :-)

[Paul Ionescu]

Hi,


On Sat, 29 Jan 2005 12:42:21 -0500, David Zeuthen wrote:

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

Usually acpid opens that socket, and nobody else can use it anymore.
Some systems are still using acpid because we don't have and viable
alternative yet.
And acpid is started before hald.
So, in this situation, I think we can first try to open /proc/acpi/event
and if that is not possible, we can open /var/run/acpid.socket where acpid
will send all acpi events, so it is a replication of /proc/acpi/event.
This way, is not an acpid dependency.


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

Theoretically yes, but on some systems, polling too often, may result in
degraded performance due to execution of acpi methods.
But for now, I can live with that.

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

OK, I will do that.

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