[PATCH] fix for acpi-addon if use/compile with acpid
hughsient at gmail.com
Wed Oct 19 09:26:11 PDT 2005
On Wed, 2005-10-19 at 18:19 +0200, Danny Kukawka wrote:
> On Wednesday 19 October 2005 14:16, you wrote:
> > This is true, but this was the intended behaviour of the addon. The
> > idea is that if acpid isn't running on start up then we assume that the
> > user doesn't have acpid installed or doesn't want to run it.
> But for this case see my first patch in the other thread. The best would be to
> enclose the whole connect (to acpid and proc) in a loop. With this solution
> you can be sure that you get proc or acpid if you compiled both in and it
> should also work with only one of the both.
Yes, I like this idea. Doesn't this solve all the permutations of acpid
and a direct connection (with lost connections)?
> > Distributions do a good job of making sure acpid is brought up before
> > HAL so afaik this is never a problem. This approach prevents the addon
> > from becoming a useless process that does absolutely nothing but try to
> > connect every 5 seconds to a non-existent event source.
> see above. The addon is only called if there is also /proc/acpi/event. Btw.
> there could be rases with parallel booting. You can't be 100% sure that acpid
> is ready if HAL starts.
> Btw. It maybe make sense to use an other intervall in the loop for the first
> connection. I want to prevent to restart hal only because the addon 'fails'.
> If the user doesn't want to use the event sources he can change easy the
Hmm, I think making this an fdi configurable is overkill. HAL can just
fallback like it is now, or do I misunderstand you?
> IMO you never should been disconneted from /proc/acpi/event. If this happen
> there is somewhere bug. In fact this message for proc should be a error
> message and not a warning in this case.
Thats what I thought, but its better just to reconnect, as 99.99% of
users won't ever see the error!
> > I was operating under the assumption that either the kernel support
> > existed or did not exist. I don't know this as a fact -- it just sort
> > of made sense that that would be the case (ie: it never disconnects you,
> > and if it's not there on startup then it won't ever be there). Does
> > anyone know this for sure?
> The kernel event source exist or did not exist, thats rigt (IMO if there
> is /proc/acpi there is also /proc/acpi/event). But it could be that the proc
> interface is in use and acpid is not running. In this case you maybe would
> like to retry to connect. Btw. if you lost the connection to proc you should
> try to reconnect and not exit.
More information about the hal