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

[David Zeuthen]

On Tue, 2005-08-02 at 13:39 +0200, Timo Hoenig wrote:
> Hi,
> 
> On Tue, 2005-08-02 at 12:18 +0100, Richard Hughes wrote:
> 
> > Isn't HAL the only thing that should be reading /proc/acpi/event?

(That's my view, FWIW, but it's another story)

> 
> Why would a kernel interface should be exclusively used by only one
> specific application?  Since the interface can only be read by a single
> process, user space is responsible to distribute those.  Our well-tried
> solution for this purpose is  acpid.

Maybe the kernel shouldn't offer an interface only to be read by one
user space application then.

> 
> > 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?
> 
> Think of updating HAL which most likely implies a restart of  hald
> without rebooting.

I don't know. I still take the position that things like the system
message bus (D-BUS) and HAL shouldn't be restarted at all because if
they can be restarted all apps needs to handle disconnect/reconnect
which makes it orders of magnitudes more complex to use.

So, if D-BUS / HAL packages are updated just require the user to reboot
like other OS'es.

> As long as HAL does not distribute ACPI events in the exact manner like
> acpid  does (socket),
> 
>       * we break user space applications relying on the socket of  acpid
>       * we run into race conditions as discussed
> 
> I'm still seeing HAL, well, yes, as the hardware abstraction layer.  We
> really should not bloat it with things like the distribution of ACPI
> events.

Well, you know, I think it's pretty insane for a multi-platform OS
kernel to actually even distribute ACPI events - it needs to be
abstracted into something that works on multiple platforms like APM, PMU
and whatever the future may bring. That's why we have things like HAL to
"fix that" so apps don't have #ifdefs all over the place.

Cheers,
David


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