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

[Timo Hoenig]

Hi,

On Tue, 2005-08-02 at 14:53 -0400, David Zeuthen wrote:

[...] 

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

These are good examples which should be very rare though, not?

Aren't you frightened by the amount of reboots you'd have to accept
while developing HAL?

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

See below.

[...]

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

I was not taking this as geek factor.  I am just enjoying my hundreds of
suspend cycles and the software updates in between without the need of
rebooting.  Maybe rebooting doesn't take long, but restoring the
workspace like it was before takes very long.

If you take reboot as 

        BIOS + kernel boot + X + restoring workplace

you will be bored by every single reboot it takes.

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

I am always looking left and right -- Windows still reboots all too
often and even though it boots up quick, the amounts of reboots are
killing too much time.

[...]
 
> > 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).

That is fine.

Back to the real problem, what is you're opinion about HAL on server
systems (high availability)?

> Cheers,
> David

See you,

   Timo

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