[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