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

[Kay Sievers]

On Tue, Aug 02, 2005 at 02:53:48PM -0400, David Zeuthen wrote:
> On Tue, 2005-08-02 at 20:13 +0200, Timo Hoenig wrote:
> > > These applications might lose events from HAL when HAL is not running.
> > > Thus they need to check the HAL state (properties) when HAL is restarted
> > > (they know from NameOwnerChanged).
> > 
> > Events can be cached or sent out asynchronous once clients are back on
> > the bus.  
> 
> No, not really. The event may refer to a device object that is now gone
> so in that way it's pretty useless.

Caching events for subscribed applications sounds like a really cracktastic
feature. If we start requiring this I will definitely look for another
project. :)

> > A concrete example which leads to serious system
> > inconsistencies would help me to understand the problem.
> 
> How about not mounting a drive you attach during an upgrade (e.g. hald
> not running)? Or how about not suspending on lid-close when upgrading
> (e.g. hald not running). We want the events from HAL to be 100%
> predictable and things like "sorry, no events during upgrades of the hal
> package" is not good enough.

We already have HAL reconnecting to DBUS if we start the bus again.
That makes development easier and I like it so far, but it's really nothing
you should ever trust to work reliably. Maybe we should consider to remove
that reconnect loop feature, that people don't start to think that way.

> > In any case, we really do not want to see systems rebooting all day long
> > because of software updates, do we?  "Other" operating systems have
> > exactly this drawback and we really should not imitate this behavior.
> > We can do it without reboots.  

> No. You simply need reboots, get over it. If not for the kernel, then to
> update e.g. D-BUS and HAL you need to take down all of userspace which,
> haha, is 99.999% equivalent to a reboot

The time Windows reboot were annoying is long gone. It works pretty well
these days, you can even replace a lot of drivers without a reboot.

The problem why the "other" OS's are doing this is basically the amount
of complexity they can handle today. The reason we don't do this is simply
by the fact, that we are just unable to handle this complexity now.
If we want to provide a similar user experience, we will require that complexity
in our system too and with that, also the reboots on update. We just
need to get used to it.

> > > Because you need to reboot anyway because of kernel updates which are
> > > probably more frequent than userland updates.
> > 
> > This might be true, but it is not an reason not to try to prevent
> > rebooting on software updates other than the kernel.

Sure we try this as long it makes sense. Most of the sane lower-level things
work very nice that way, especially if the kind of data they manage can be
exported to the filesystem. But complex setups like the desktop with that high
grade of stateful intercommunication will never work that way and if we start
requiring this, we will get lost in a maintenance nightmare.

> > > I believe we already have this today with HAL - what are you missing?
> > 
> > There are drivers (IBM ACPI, Panasonic ACPI, Sony ACPI just to name a
> > few) generating ACPI events which are not handled by HAL and thus get
> > lost if HAL claims /proc/acpi/event.  Yes, there is a generic hotkey
> > driver on its way to make the specific drivers obsolete but it does not
> > yet provide the wide range of functionality the specific ones do.
> 
> Just start acpid before hald and everything will be fine.

That sounds acceptable to me, if it's not, the network guys are currently
trying to get a finer-grained netlink subscription mechanism. If that will
show up, we should be able to add a sane interface to the kernel to provide
these events to multiple listeners.
If we can't wait for that, I may look into using the kobject_uevent
interface if there is really a requirement for it at that level ...

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