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

[Timo Hoenig]

Hi,

On Tue, 2005-08-02 at 11:43 -0400, David Zeuthen wrote:
> On Tue, 2005-08-02 at 13:39 +0200, Timo Hoenig wrote:
 
> > 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.

Agreed.  I'll start a discussion about this on acpi-devel.  Hopefully it
doesn't end in a "what can be done in user space, should be done in user
space".

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

Agreed regarding the D-BUS system bus, but not HAL.  Client applications
waiting for messages of HAL being sent on the system bus are happily
working even if HAL gets restarted.

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

I do not think that this makes sense.  We've come so far with STR and
STD which makes rebooting of a properly installed system almost
unnecessary.  We manage hotplugging of devices, even of CPUs.  So why
should we not seek for a solution where software updates do not enforce
a system reboot?

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

I don't like to gather events about discharging batteries and hotkeys on
one and the same interface either...

Since we're living in the ACPI world nowadays, what's your opinion?  We
have the ACPI events to rely on.  So should we get rid of  acpid  and
implement an abstract event interface using HAL?  

> Cheers,
> David

See you,

   Timo

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