Az egyik fejlesztő a Google-tól az LLVM levelezőlistáján a többplatformos standard C könyvtár (Libc) fejlesztésének témáját az LLVM projekt keretében. Számos okból a Google nem elégedett a jelenlegi libc-kkel (glibc, musl), és a vállalat új megvalósítás fejlesztésén dolgozik, amelyet az LLVM részeként ajánlanak fejleszteni.
Az LLVM fejlesztései mostanában a Google telepítési eszközkészletének alapjaként szolgálnak. A fő ötlet az, hogy ha a Google már elkezdte a libc fejlesztését, akkor miért ne fejlesztené az LLVM részeként a saját rendszerét, amely már biztosít egy standard könyvtárat C++-hoz (Libc++), de nem rendelkezik hasonló standard könyvtárral a C-hez (Libc).
A fejlesztést lépésről lépésre tervezik végezni, fokozatosan növelve a funkcionalitást. Az első verziókat egy alkalmazás és a rendszer Libc közötti réteg formájában javasolják kialakítani, ahonnan a még meg nem valósított lehetőségeket fogják átvenni. Miután elértek egy bizonyos funkcionalitási szintet, az új Libc használható lesz a rendszer Libc teljes helyettesítéseként. A fejlesztést az x86-64 architektúra, Linux és statikus linkelés támogatásával tervezik kezdeni (a dinamikus betöltés, a kötés és a további architektúrák második lépésben valósulnak meg).
A projekt még csak a kezdeti fejlesztési szakaszban van, de már meghatározták az alapvető célokat:
- Modularitás és fejlődés a granularitásra épülő könyvtár átadásának filozófiája szerint, nem egy monolitikus készlet szerint;
- A statikus linkelés támogatása (Pozíciófüggetlen végrehajtások) üzemmódokban és anélkül. CRT (C futási környezet) és PIE betöltő biztosítása statikusan linkelt végrehajtható fájlokhoz;
- A standard C könyvtár funkcióinak legnagyobb részének támogatása kiegészítőkkel a POSIX és néhány meglévő alkalmazásokhoz szükséges rendszer-specifikus kiterjesztésekkel;
- Óvatos hozzáállás a gyártók általi kiterjesztésekhez és azok csak szükség szerint való hozzáadása. A harmadik féltől származó kiterjesztések támogatásának tekintetében a Clang és libc++ projektek megközelítését javasolják;
- A fejlesztésben az LLVM eszközkészlet használatával kapcsolatban mintaszerű gyakorlatok alkalmazása, mint például a sanitizer és a fuzzing tesztelés az elejétől fogva.
Az LLVM egyik aktív fejlesztője , hogy az LLVM eszközkészletéhez tartozó libc szállítása nem értelmetlen, de általában, ha ilyen szükség van, a musl könyvtárat használják, amely jól megírt, támogatja a különböző architektúrákat, és biztosítja a szükséges funkcionalitást, beleértve a dinamikus kötést is. A musl LLVM-be való beépítése és a fő projekttel szinkronizált fork-ként való fejlesztés indokolt lehet.
A véleményét szintén a Musl projekt szerzője, aki megpróbálta megindokolni, hogy miért rossz ötlet a Google javaslata és a Libc belefoglalása az LLVM szállítmányába:
- A helyes, kompatibilis és magas minőségű Libc fejlesztése és karbantartása nagyon nehéz feladat. A probléma nem a kód mennyiségében rejlik, hanem a helyes működés biztosításában és a C/C++ nyelven valaha írt alkalmazások, valamint más nyelveken készült alkalmazások interfészeinek megvalósításának nehézségeiben, amelyek runtime-ja Libc-t használ. A frontalitás figyelmen kívül hagyása csak ahhoz vezet, hogy sok meglévő program nem tud együttműködni a Libc-vel, de akkor egy ilyen projekt nem lesz vonzó a fogyasztók számára.
- A vállalati fejlesztés tönkreteheti a Libc-t, de széles körű használatra erőltethető, aminek végeredménye, hogy hackekre lesz szükség a kompatibilitás biztosításához az alkalmazásokban. A vállalati nyílt projekt égisze alatt történő fejlesztés csak a cég igényei és megoldásai felé fogja húzni a takarót, a közösség érdekeinek kárára. Például, ha egy probléma merül fel, amely egy másik saját programjuk hibájából adódik, a kontrollált fejlesztésben könnyebb biztosítani a Libc kompatibilitását ezzel a hibával, mint magát a hibát javítani. Az Apple a BSD libc forkját használja ezekre a célokra, míg a Google a Fuchsia esetében a musl forkját alkalmazza. A musl fejlesztő tapasztalata szerint vele főleg jogászok léptek kapcsolatba a licencelési kérdések tisztázására, de soha nem fordultak technikai részletek tisztázásával, mielőtt haszontalan és a működést zavaró változtatásokat vezettek volna be a saját ágaikba.
- A libc fejlesztésénél a monokultúra hiánya és a konszenzusos alapú szabványok iránti orientáció, ahelyett, hogy egyedüli irányítás lenne, motiválja a fejlesztőket arra, hogy a szabványokat használják, és ne kössék magukat konkrét megvalósításokhoz. Éppen ezért a musl szerzője ellene van annak, hogy a könyvtárát belevonják az LLVM-be, ahogy a libc LLVM keretein belüli fejlesztését is ellenzi, mert ekkor elveszíti a libc független jellegét, és egy adott megvalósítás első osztályú megoldássá válik az LLVM számára, míg minden más másodlagossá válik.
Forrás: opennet.ru
