[PATCH] command line options for hald-addon-acpi

Richard Hughes hughsient at gmail.com
Tue Aug 2 04:18:48 PDT 2005


On Tue, 2005-08-02 at 13:15 +0200, Timo Hoenig wrote:
> Hi,
> 
> On Tue, 2005-08-02 at 11:56 +0100, Richard Hughes wrote:
> 
> > On Tue, 2005-08-02 at 12:53 +0200, Timo Hoenig wrote:
> > > I don't see the benefit of having this as an configure/compile time
> > > option.  Please clarify.
> > 
> > Well, how would we specify the acpi event source from the command line?
> > acpi-addon is launched internally by hald - so we would have to change
> > the command line to add the new arguments inside hald.
> 
> I can only see callouts to  hal-addon-acpi  with information provided by
> 10-power-mgmt-policy.fdi  ...

Okay, my error, sorry.

> > How could a race occur with the current scheme? Sorry if I'm being a bit
> > thick.
> 
>       * acpid is running, dispatching events via its socket
>       * process A is running, using acpid socket to receive ACPI events
>       * process B is running, using acpid socket to receive ACPI events
>       * acpid dies or gets restarted
>       * race between A and B if they both fallback on
>         reading  /proc/acpi/event  directly.  
> 
> At this point no process will be able to receive ACPI events but the one
> which won the race because  /proc/acpi/event  can only be read by a
> single process at once.

I see what you mean.

Isn't HAL the only thing that should be reading /proc/acpi/event?
Anything else is legacy code that should be using the hal-backend
anyway. I figure ACPI isn't likely to be restarted for the duration of
the session. Is this too harsh?

Richard.

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



More information about the Hal mailing list