"hal deprecation" - Was bedeutet das für FreeBSD?

cabriofahrer

Well-Known Member
In neuen Releasenotes (http://www.ubuntu.com/getubuntu/releasenotes/910overview)
für das in drei Tagen erhätliche Ubuntu 9.10 steht u.a., daß "hal" bald Geschichte sein wird und durch "DeviceKit-power", "DeviceKit-disks" und "udev" ersetzt wird.
Was bedeutet das für FreeBSD? Grund zur Freude, nachdem man hier im Forum immer sehr viel Unmut zu hal vernehmen konnte?
Ich nehme an, daß das kommende 8.0 diesbezüglich noch keine Änderungen bringt, auch nicht bezüglich "UXA", wie weiter unten im Artikel erwähnt wird?
 
Unsere Meinung zu HAL ist hier wohl bekannt. HAL ist ein großen Polling Monster das von allen Ecken und Enden des Systems Informationen Zusammfriemelt.

FreeBSD bietet mit devd eine Möglichkeit Listener zu registrieren, was prinzipiell eine viel bessere Lösung ist, da es zuverlässiger als Polling ist und nur dann Last erzeugt, wenn tatsächlich etwas passiert. Das die Linux-zentrische Xorg-Welt da auf HAL gesetzt hat frustriert uns natürlich ungemein, da wir eine einfachere und besser Lösung haben und uns trotzdem mit dem Murks abgeben müssen.

DeviceKit ist in meinen Augen wirklich nur dann eine richtige Verbesserung, wenn es soweit möglich unter FreeBSD auf devd aufsetzt.
 
Ich habe keine konkreten Informationen dazu (und habe mich auch nicht darum bemüht), aber ich erwarte nicht, dass es dazu kommt. Ich freue mich natürlich über jede gegenteilige Information.
 
Ich weiß auch nur, dass es portiert wird und dank Gnome 3 werden muss. Aber auch nicht, in welcher Form es passieren wird. Ideal wäre natürlich, wenn es wirklich auf devfs und kqueue aufsetzten würde. Aber ich glaube, dass passiert nicht. Es wird wohl eher weiterhin ein riesiger Wrapper um Linux /proc und /sys bleiben, den man irgendwie an den FreeBSD-Kern anflanschen muss.
 
Hm, eigentlich müsste doch nur das Interface stimmen. Man kann also ruhig etwas eigenes implementieren. Müsste halt nur jemand machen, mit dem Unterschied, dass es halt auch immer weiterentwickelt werden müsste (wie DeviceKit).
Wenn man einmal das proc zurechtfrickelt muss man danach wahrscheinlich erstmal nicht so viel updaten.
 
Ich glaube, eine anstaendige Abstraktion und dann das OS spezifische und Beste nutzen. Auf alle Faelle kein proc nachbauen und zurechtfrickeln, wenn man mit devd was Besseres hinbekommen kann.
 
total OT

Ich will jetzt kein Linux gebashe lostreten, aber das ist wiedermal ein Paradebeispiel für die Unorganisiertheit von Linux. Xorg setzt seit nicht allzu langer Zeit auf hal und hal wird nun begraben. Ich wäre jetzt gerne mal Mäuschen und würde beim Xorg DevTeam lauschen wollen.

Gruß c.
 
Also laut der Datei NEWS im Source Tree, setzt es auf udev auf. Inwieweit das von procfs abhaengt, weiss ich nicht.

Vielleicht kann dann "einfach" udev durch devd ersetzt werden.

Aber basteln die im Linux Kernel nicht gerade an einem Ersatz fuer udev?
 
Ja, nachdem man das im Kernel lebende devfs durch diesen im Userspace laufenden udev ersetzen musste, entschied der Guru nun, dass man doch wieder devfs wünscht. :)
 
Oh mann, wie oft ich auf Messen schon gehört habe "Was? Ihr benutzt devfs? Aber für Linux war das doch viel zu schlecht! udev ist viel besser!" :-s
 
Ohne nun zu sehr ins Offtopic zu driften, aber udev ist ein einziger Haufen Müll. Wie oft habe ich schon den Code lesen müssen - da es keine brauchbare Doku gibt - um herauszufinden, wieso das Mistding plötzlich Regeln nicht mehr akzeptiert, die am Tag zuvor noch funktionierten und solche Spielchen. Dies Ding steht qualitativ gesehen auf der gleichen Ebene wie hal oder polkit. Ich habe nie verstanden, was an dem Ding besser sein soll, als an devfs. Aber gut, auch Linux devfs war ein wenig "eigen".
 
Die Dinger an sich wären ja garnicht so schlimm wenn man nicht alle zwei Jahre immer neuanfangen würde und das jeweils letzte beerdigen. Für BSD (und wahrscheinlich alles non-linux) ist das besonders unpraktisch, da meisten das jeweils letzte erst richtig funktioniert, wenn es unter Linux schon deprecated wird.
Obwohl das bei den Linuxern doch sicher auch Ärger machen muss. Außer man nimmt Debian Stable und übersrpingt einfach jede zweite Iteration ;)
 
Zurück
Oben