Das udev Drama
Ich bin ein alter Sack. Ich habe keine Verwendung für Automatismen auf meinem Rechner, denn mein Rechner ist größtenteils statisch. Und ich kompiliere alles aus den Sourcen. Aber das wird zunehmend schwierig. Ein Grund ist die Einstellung von Entwicklern, hier exemplarisch am Beispiel von systemd.
Beim Kompilieren der MesaLib 10.0.3 konnte ich keine Verbindung zu dem drm-Backend im Kernel herstellen, um an die Hardwareunterstützung zu kommen. Das ist ärgerlich.
Noch ärgerlicher ist es, wenn man feststellt, daß dies dem Fortschritt geschuldet ist. Die Entwickler der MesaLib haben für die Ermittlung der Device-Eigenschaften auf die libudev API zurückgegriffen. Sie brauchen nicht viel, sparen sich dafür aber eine ganze Menge eigenen Code. Dies ist eine grundsätzlich gute Idee.
Nur hat mein System kein udev. Ich mag diese Dynamik nicht. Mir reicht schon, wenn die Devices mit devtmpfs auftauchen und ich meine speziellen Devices von Hand hinzufügen kann. Ich bin halt alt und gewöhne mich nicht mehr so schnell um. Das Linux was ich benutze hat die Wurzeln im Yaggdrasil, wurde von Slackware beeinflußt und zuletzt mit Hilfe von LinuxFromScratch aktuell gehalten. Aber dazu muß ich mal separat bloggen.
Die aktuelle Version von libudev ist Bestandteil von systemd. Aber irgendwie kann ich die nicht separat compilieren.
- Der offizielle Tarball enthält kein Makefile.
- Es gibt keine configure Option, die libudev separat zu kompilieren.
- In dem gemeinsam für alles benutzten Makefile finde ich ad hoc kein Ziel die libudev getrennt zu erzeugen.
- Da ich die Voraussetzungen von systemd nicht erfülle, erstellt mir das configure auch kein Makefile.
Das ist doof.
Also schau ich mir mal an, was libudev eigentlich so tut. Aber den Blick in den Source hätte ich nicht wagen sollen:
- Die Funktion print_kmsg in libudev-util.c prüft den Rückgabewert von vsnprintf nicht. Der anschließende write syscall kann also Bereiche außerhalb des Buffers ansprechen.
- Es wird statt queue.h eine eigene Implementation von Listen verwendet.
- Es wird praktisch ausschließlich Stringverarbeitung auf Pfadnamen gemacht. Das sieht aus, als hätte jemand ein Shell oder awk-Script nach C portiert.
- Es werden zwingend die Kernelfilesysteme sysfs unter /sys, procfs unter /proc und devtmpfs unter /dev erwartet. Eine Verwendung anderer Pfade ist nicht vorgesehen.
- Runtime-Daten und Konfigurationdaten liegen unter den hart einkompilierten (und nicht änderbaren) Pfadnamen /run, /udev/queue.*, /etc/udev/udev.conf und /etc/udev/hwdb.bin. Ich habe aber z.B. /var/run.
- Der Code benutzt netfilter und andere Kernelerweiterungen, die hier nicht zwingend gegeben sind. Insbesondere werden sehr aktuelle Versionen von glibc (keine anderen libc) und Linux Kernel (> 3.0) vorausgesetzt. Auch das ist nicht zwingend gegeben, schließlich habe ich auch noch Kisten für deren Prozessoren es keine aktuellen Linux Kernel mehr gibt.
Diesen Code will ich gar nicht haben.
Aber was dann? Ich schreibe mir die paar Funktionen als libudev-light selbst. Zum Anfüttern das Readme.
libudev is deeply connected into a set of dependencies. Most of them caused by the systemd environment and are not strictly necessary. The usage of libudev it to map device names and device properties. This task should be solvable without the additional depencencies and for a wide range of systems and environment. libudev-light is designed as a plugin library for client software which prefers the abstraction of the libudev API but will run also on systems which does not offer the full blown udev environment. Philosophy ~~~~~~~~~~ libudev-light should cover any runtime environment. It should use the correct and therefor usually system depended methods to solve it's task. It should provide an common abstaction layer to the platform specific nifties. This will require a lot of compile time dependencies, vast amounts of typically unused code for obscure environments, and complex configuration time efforts. Any patch is welcome as long it adds special environments. There is no need to remove code soley to "clean up" something. Historical systems should be supported as long as they might exist. The lib is intended to ease porting modern applications to older systems, so old code exists on purpose. libudev-light will only add the really required features by need, it does not aim to cover the full blown API of the libudev. Every addition needs a reference to an application calling this API in question. Of course it is a bug, if a call is missing. OTOH a narrow API eases development and porting to unusual environments. So libudev-light is always work in progress. Porting will struck if a specific task can't be determined on the given system. The information in question might not exists, is not exposed, or the method to retrieve the information is not known. In such cases an explicit configuration file can be queries. There is no harm in obtaining information about the system from a configuration file! If you port this application, please feel free to introduce such a file, whenever necessary. Compatibility ~~~~~~~~~~~~~ libudev-light should offer a backward compatible API and ABI. Due to the opportunity to extend the API, the library might need and offer frequent updates. Updating the library should not break already compiled applications, especially in the case of shared linkage. The major number of the shared lib should only change if unavoidable, in order to evolve the lib without splitting it into an "old ABI" and "new ABI" branch. Installing the new lib should always allow i.e. ldconfig to change the symbolic link to the new library and remove the old one as soon as possible. Lutz Donnerhacke
Mal sehen, wann MesaLib mit egl-driver="drm" läuft.
mich nervt die ganze systemd-Geschichte auch enorm. Und das obwohl (oder vielleicht gerade) weil ich seit vielen Jahren bevorzugt Binärdistros (Debian/Ubuntu) einsetze und nur noch wirklich bei Bedarf selbst paketieren möchte.
Mittlerweile wird das aber so schlimm, daß wir alten Leute mal einschreiten und den Unfug wieder gradeziehen müssen. Wenn ich das Ding wirklich mal anfasse (was ja wohl mit den aktuellen Debian-Entscheidungen zunehmend unvermeidlich wird), dann würde
ich mich auch mal ein paar Tage hinsetzen und der Lennart-Sekte mal zeigen, wie
man richtige IPC-Interfaces macht - also 9P.
Vielleicht sollten wir uns demnächst mal zum Thema zusammentelefonieren ...
Weiß aber nicht, wie benutzbar das gerade ist.
Total 3 comments