Een van de ontwikkelaars van Google in de LLVM-mailinglijst het onderwerp aangesneden van de ontwikkeling van een multiplatform standaard C-bibliotheek (Libc) als onderdeel van het LLVM-project. Om verschillende redenen is Google ontevreden met de huidige libc-implementaties (glibc, musl) en het bedrijf is bezig met de ontwikkeling van een nieuwe implementatie, die als onderdeel van LLVM moet worden uitgebreid.
De ontwikkelingen binnen LLVM worden momenteel als basis gebruikt voor de bouwgereedschappen van Google. Het belangrijkste idee is dat als Google al bezig is met de ontwikkeling van zijn libc, waarom zou het dan niet meteen zijn systeem ontwikkelen binnen LLVM, dat al zijn eigen standaardbibliotheek voor C++ (Libc++) biedt, maar geen soortgelijke standaardbibliotheek voor C (Libc).
De ontwikkeling is gepland in fasen, waarbij geleidelijk de functionaliteit wordt uitgebreid. De eerste versies worden voorgesteld als een laag tussen de applicatie en de systeem Libc, waarvan nog niet gerealiseerde mogelijkheden zullen worden overgenomen. Na het bereiken van een bepaald niveau van functionaliteit kan de nieuwe Libc dienen als een volledige vervanging voor de systeem Libc. Er wordt begonnen met ondersteuning voor de x86-64-architectuur, Linux en statisch linken (dynamisch laden, samenvoegen en extra architecturen zullen als tweede worden geĆÆmplementeerd).
Het project bevindt zich momenteel in een vroege ontwikkelingsfase, maar de basisdoelen zijn al vastgesteld:
- Modulariteit en ontwikkeling in overeenstemming met de filosofie van het leveren van een gefragmenteerde bibliotheek in plaats van een monoliet pakket;
- Ondersteuning voor statisch linken in modi met (position-independent executables) en zonder PIE. Het bieden van CRT (C-runtime) en een loader voor PIE voor statisch linker uitvoerbare bestanden;
- Ondersteuning voor het merendeel van de functies van de standaard C-bibliotheek met POSIX-aanvullingen en sommige systeem-specifieke uitbreidingen die nodig zijn in bestaande applicaties;
- Voorzichtig omgaan met leveranciers-specifieke uitbreidingen en deze alleen toevoegen waar nodig. Wat betreft de ondersteuning van externe uitbreidingen wordt voorgesteld om de aanpak van de Clang- en libc+-projecten toe te passen;
- Gebruik maken van best practices in de ontwikkeling met de hulpmiddelen van LLVM, zoals het toepassen van sanitizers en fuzzing-testen vanaf het begin.
Een van de actieve ontwikkelaars van LLVM , dat de levering van libc binnen de LLVM-toolkit zinvol is, maar gewoonlijk, bij dergelijke behoefte, de musl-bibliotheek wordt gebruikt, die kwalitatief goed geschreven is, verschillende architecturen ondersteunt en de benodigde functionaliteit biedt, waaronder ondersteuning voor dynamische koppeling. Het kan gerechtvaardigd zijn om musl in LLVM te integreren en het te ontwikkelen als een geforkte versie die gesynchroniseerd is met het hoofdproject.
Ook zijn mening door de auteur van het Musl-project, die heeft geprobeerd te argumenteren waarom het voorstel van Google om Libc in de levering van LLVM op te nemen, zeer slechte ideeƫn zijn:
- De ontwikkeling en ondersteuning van een correcte, compatibele en hoogkwalitatieve Libc is een zeer moeilijke taak. Het probleem ligt niet in de omvang van de code, maar in het waarborgen van correct gedrag en de moeilijkheden bij het implementeren van interfaces, rekening houdend met de enorme hoeveelheid ooit geschreven applicaties in C/C++, evenals applicaties in andere talen waarvan de runtime gebruik maakt van Libc. Een directe aanpak zonder rekening te houden met nuances zal er alleen toe leiden dat veel bestaande programma's niet kunnen werken met Libc, maar dan zal zo'n project niet interessant zijn voor consumenten.
- Corporate ontwikkeling kan Libc verpesten, maar wordt doorgedrukt voor breed gebruik, wat resulteert in de noodzaak om hacks toe te voegen voor compatibiliteit in applicaties. Ontwikkeling onder de vlag van een corporate open project zal de focus verleggen naar de behoeften en oplossingen van het bedrijf, ten koste van de belangen van de gemeenschap. Bijvoorbeeld, in het geval van het ontdekken van een probleem dat wordt veroorzaakt door een fout in een andere van hun programma's, is het onder controle gehouden ontwikkelteam gemakkelijker om Libc compatibel te maken met deze fout dan de fout zelf te verhelpen. Apple gebruikt voor deze doeleinden een fork van de BSD libc, terwijl Google in Fuchsia een fork van musl toepast. De ervaring van de musl-ontwikkelaar toont aan dat hij voornamelijk door advocaten werd benaderd voor vragen over licenties, maar nooit voor technische details alvorens nutteloze en storende wijzigingen in hun takken aan te brengen.
- Het gebrek aan monocultuur bij de ontwikkeling van libc en de focus op consensus-gebaseerde standaarden in plaats van eenmansbeheer, stimuleert ontwikkelaars van applicaties om standaarden te gebruiken in plaats van zich te binden aan specifieke implementaties. Daarom is de auteur van musl tegen het opnemen van zijn bibliotheek in LLVM, evenals tegen de ontwikkeling van libc binnen LLVM, omdat dit de onafhankelijkheid van libc zou ondermijnen en een bepaalde implementatie een first-class oplossing voor LLVM zou maken, terwijl alle andere als second-class worden beschouwd.
Bron: opennet.ru
