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

[David Zeuthen]

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.

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

> 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 (that's where we want to go,
plus keep in mind that the kernel boots fast these days and most fs'es
uses journaling). Same applies for X.org updates: logging in/out of your
desktop session is basically equivalent to rebooting from a user
perspective.

Btw, to avoid reboots, we just need to ensure that neither HAL nor D-BUS
[1] needs software updates that often. What does this mean? It means we
want to freeze for 1.0 at some point and make sure that the code is
robust and secure. But when there are (security) updates we need the
user to reboot as soon as possible for the update to take effect. Once
we have a frozen API the user never needs to reboot unless the update is
a security update.

I hope this clarifies.

[1] : this really applies to all software in the OS I think

> Wait, just let me check my uptime... ;-)

I just don't know about statements like that. Uptime is really just a
geek-factor, what we want is a robust, secure and predictable system.
You mention "Other" operating systems - well, I don't think the
mainstream Linux-based systems are doing better, in fact I think Windows
XP SP2 is pretty darn good in terms of both user experience and making
sure security patches get applied. But that is of course my personal
somewhat uninformed opinion (I'm not a security expert by any means).

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

And X... Seriously, people have to get over this knee-jerk reaction with
that reboots are evil. Try to look at it from an end-user perspective
(logging in and out of the desktop session == reboot) instead of
"omigod! my uptime is super high" =).

> > 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. Btw, we will
add support for vendor-specific drivers at some point in HAL (as well as
the new generic hotkey driver).

Cheers,
David


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