Software::Entwicklung
Ausblick auf glibc 2.10
glibc-Entwickler Ulrich Drepper hat die Änderungen in der kommenden Version 2.10 von glibc vorgestellt.
glibc ist die Laufzeitbibliothek für Programme, die in der Programmiersprache C geschrieben sind. Da auch C++ davon Gebrauch macht und viele Interpreter für andere Sprachen selbst in C geschrieben sind, hängt letztlich ein Großteil der unter Linux laufenden Software von glibc ab.
Mehrmals erwähnt Drepper, der für Red Hat arbeitet, in seinem Artikel die Linux-Distribution Fedora, deren kommende Version 11 als eine der ersten Distributionen glibc 2.10 enthalten wird.
glibc wird nach Auskunft von Drepper fast vollständig zu POSIX 2008 konform sein. Drepper ist selbst Mitglied der »Austin Group«, die POSIX 2008 spezifiziert hat. Der Großteil der Arbeit bestand darin, Funktionen, die in der glibc bereits vorhanden waren, in die Spezifikation zu übernehmen. »Die Unix-Welt schließt zu Linux auf«, sagt Drepper hierzu. Nur wenig bleibt zu tun, um glibc 2.10 vollständig POSIX-konform zu machen. Für die Implementation der Flags O_SEARCH und O_EXEC wird allerdings entsprechende Unterstützung im Kernel benötigt.
C++-Programmierer müssen sich vorsehen, da einige neue Funktions-Prototypen hinzugefügt wurden. Einige Aufrufe, die bisher noch funktionierten, obwohl sie laut Drepper inkorrekt waren, lassen sich nun nicht mehr compilieren. Neu hinzu kamen auch einige Funktionen, die zur effizienten Unterstützung des kommenden Standards C++ 201x benötigt wurden.
Die DNS-Abfragen im Name Switch Service (NSS) waren bereits in glibc 2.9 optimiert worden. Diese Optimierung führte jedoch dazu, dass die Software mit fehlerhaft implementierten Nameservern nicht funktionierte, und musste daher deaktiviert werden. In glibc 2.10 kehrt die Optimierung zurück, wechselt aber automatisch in den alten Modus zurück, wenn glibc erkennt, dass sie nicht funktioniert. Da dies beim ersten Aufruf in jedem Programm zu einer Verzögerung führen kann, gibt es auch eine Option, das alte Verhalten zum Standard zu machen.
Die Verschlüsselungs- und Hash-Funktionen von glibc können nun von den Network Security Services (verwirrenderweise ebenfalls NSS genannt) Gebrauch machen. Deren Vorteil besteht darin, dass sie EAL-zertifiziert sind. Durch die Möglichkeit, auf bereits zertifizierten Code zuzugreifen, kann eine vollständig zertifizierte Passwort-Verwaltung aufgebaut werden, ohne dass der aufwändige Prozess der Zertifizierung erneut durchlaufen werden muss.
Die printf-Funktion in glibc war schon früher erweiterbar, um andere Formate ausgeben zu können. Diese Schnittstelle genügte aber nicht mehr den aktuellen Anforderungen und wurde daher geändert. Drepper beklagt, dass der Standardisierungs-Prozess (der Programmiersprache C) wieder einmal von Interessengruppen unterwandert worden sei. Dadurch seien Erweiterungen geschaffen worden, um dezimale Gleitkommaberechnungen durchführen zu können, was von 99,99% der Anwender nie benötigt werde. Drepper lehnt es ab, diese Erweiterungen zu implementieren, und wenn der Standard in Kraft treten sollte, dann sollten die Erweiterungen separat von der glibc bleiben. Lediglich die Erweiterung der Funktion printf wurde wie oben beschrieben vorbereitet.
Eine weitere Neuerung soll die Skalierbarkeit von malloc verbessern. Es soll nun einen Speicherpool pro Thread geben, mit einer Begrenzung auf acht Pools pro CPU-Kern (zwei Pools bei 32 Bit). In einigen Fällen soll dadurch die Geschwindigkeit von Programmen drastisch steigen. Eine weitere Änderung der Speicherverwaltung betrifft die kaum bekannte Funktion mallinfo. Diese hatte zahlreiche Mängel, die durch eine neue Implementation behoben wurden. Die Ausgabe der Funktion ist jetzt eine sich selbst beschreibende XML-Datei, die von externen Werkzeugen analysiert werden kann.
Als letzte große Neuerung wird glibc 2.10 automatisch von Funktionen Gebrauch machen können, die für einen bestimmten Prozessor optimiert wurden. Solche Funktionen werden mitunter von den Prozessorherstellern bereitgestellt. Um die automatische Auswahl der besten Funktion ohne Laufzeit-Overhead zu ermöglichen, definierte Drepper einen neuen Abschnitt für das ELF-Dateiformat. Das Auswerten dieses Abschnitts dürfte die Startzeit von Prozessen minimal erhöhen. Die Auswirkung in der Praxis lässt sich noch nicht so einfach testen, da das Feature in Fedora 11 noch abgeschaltet sein wird. Laut Drepper müssen noch die binutils und das Prelinking angepasst werden.
