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

[Danny Kukawka]

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.

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

> > > With this patch I also changed the position of the defines for acpid
> > > and kernel proc event source to remove unneeded function call.
>
> Please don't do this.  This was also intentional.  This approach is the
> generally recommended method (books, etc) since, even though it has the
> potential for call overhead the overhead is -very- small (possibly zero
> if the compiler inlines) and there are other advantages (better
> abstraction, no compiler warnings about unused functions, etc).

I saw this compiler warning first after sending the patch. But you can enclose 
the functions and functioncalls with ifdef also without this error message. 
And I see no reason to call a function if we already know at compile time 
that we never call the function. This is cleaner for me than comment out 90 
percent of the function body.

> You should consider rephrasing this warning.  It's not just thrown when
> you've failed to connect, but also when you've merely been
> disconnected.

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.

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

Cheers,

Danny