[rant] keeping policy in HAL

[Klaus Dittrich]

Nix wrote:
> On 1 Dec 2008, David Miller verbalised:
>
>   
>> A default that, btw, anti-socially totally ignores what people put
>> into their xorg.conf file unless they add yet another knob.  That's
>> worse than a default change.
>>     
>
> What's worse yet is that hal is the single most unstable daemon I have
> *ever* run on any system I administer. My logs show that for more than
> half the time over the last two years it has refused to start: it
> coredumped on startup for a long time, for reasons that changed two or
> three times as I tracked the development HAL in hopes of it getting
> fixed, then started working, then some change in 2.6.27 made it freeze
> on startup: this now seems to be fixed in the stable tree, but, still,
> robust software this is not.
>
> I didn't care enough to track any of these problems down myself because
> on my fixed-hardware desktop HAL is basically a waste of memory: the
> hardware doesn't change and I know what I've got. I checked enough to
> make sure there was a bug reported, then moved on.
>
> So I was... somewhat annoyed to discover that when upgrading to xserver
> 1.5.3 I had to add 'AllowEmptyInput false', particularly given that the
> option name gives you no clue whatsoever as to why on earth this would
> make the keyboard reappear, and even the git logs give no rationale. I
> still have no idea why anyone would consider this behaviour desirable,
> particularly if you're loading kbd but are not loading evdev.
>
> IMHO, if the daemon isn't running at all, AllowEmptyInput should be
> unnecessary, and kbd/mouse should be consulted if loaded, *whether or
> not* the server was compiled with HAL support.  Anything else is just
> too prone to failure.
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>   
I actually run Xserver-1.5.2 and for my needs it works very well.

A try of Xserver-1.5.3 without HAL ended up with a totally unusable system.
No screen, no keyboard, no ability to switch back to a text console.
Last resort was the reset-button.

Same Xserver-1.5.3, this time with HAL and d-bus.
Surprise, X11 came up, the keyboard worked, but after a view minutes
the system became sluggish.

A view into /var/log/messages showed lots of block errors of my system
disk and a short time later the system became totally unusable.
Again the reset button.

The disk is and was 100% ok!
Any hints how to prevent HAL from damaging scsi/sata io are welcome.

Having had these experiences I think X should not only not rely on HAL,
it should never rely on HAL, meaning HAL should be an option.
And in its current state, this option should be marked as highly
experimental.

I would suggest an additional mode of HALD in which it can be started
in an non-daemon mode with an filename as argument.

In this file HAL should then write what X11 input/output devices it believes
to have discovered, best in a notation directly usable for insertion in 
xorg.conf,
and then exit.

This way HAL can be developed further without being annoying to users
with fixed desktops and/or small systems and xorg.conf stays usable
for a reliable configuration.

--
Klaus