[PATCH] fix for acpi-addon if use/compile with acpid

[Richard Hughes]

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

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.

Yes, agreed.

Richard.