Jeden z vývojárov zo spoločnosti Google na konferencii LLVM o vývoji multiplatformovej štandardnej knižnice C (Libc) ako súčasti projektu LLVM. Google z viacerých dôvodov nie je spokojný so súčasnou knižnicou libc (glibc, musl) a spoločnosť je na ceste k vývoju novej implementácie, ktorej vývoj sa navrhuje ako súčasť LLVM.
Vývoj LLVM bol nedávno použitý ako základ pre zostavenie montážnych nástrojov Google. Hlavnou myšlienkou je, že ak Google už začal vyvíjať svoju knižnicu libc, tak prečo okamžite nevyvinúť svoj systém ako súčasť LLVM, ktorý už ponúka vlastnú štandardnú knižnicu pre C++ (Libc++), ale nemá podobnú štandardnú knižnicu pre C (libc).
Vývoj je naplánovaný na etapy s postupným zvyšovaním funkčnosti. Prvé možnosti navrhujeme navrhnúť ako vrstvu medzi aplikáciou a systémom Libc, z ktorej sa prevezmú funkcie, ktoré ešte neboli implementované. Po dosiahnutí určitej úrovne funkčnosti je možné nový Libc použiť ako úplnú náhradu za systém Libc. Plánujeme začať s podporou architektúry x86-64, Linuxu a statického linkovania (dynamické načítavanie, linkovanie a ďalšie architektúry budú implementované sekundárne).
Projekt je stále v počiatočnom štádiu vývoja, ale základné ciele už boli definované:
- Modularita a vývoj v súlade s filozofiou dodania granulárnej knižnice a nie monolitickej sady;
- Podpora pre statické prepojenie v režimoch (spustiteľné súbory nezávislé od pozície) a bez PIE. Poskytovanie CRT (C runtime) a PIE zavádzača pre staticky prepojené spustiteľné súbory;
- Podpora väčšiny štandardných funkcií knižnice C, s doplnkami POSIX a niektorými systémovo špecifickými rozšíreniami, ktoré vyžadujú existujúce aplikácie;
- Pri rozšíreniach špecifických pre dodávateľa buďte opatrní a pridávajte ich iba v prípade potreby. Čo sa týka podpory rozšírení tretích strán, navrhuje sa použiť prístup projektov Clang a libc++;
- Používanie osvedčených postupov pri vývoji pomocou súpravy nástrojov LLVM, ako je používanie dezinfekčných prostriedkov a testovanie fuzz od úplného začiatku.
Jeden z aktívnych vývojárov LLVM Je jasné, že má zmysel dodávať libc ako súčasť LLVM toolkitu, ale zvyčajne, keď takáto potreba nastane, použijú knižnicu musl, ktorá je dobre napísaná, podporuje rôzne architektúry a poskytuje potrebnú funkcionalitu vrátane podpory dynamického prepojenie. Môže byť opodstatnené vložiť musl do LLVM a vyvinúť ho ako vidlicu synchronizovanú s hlavným projektom.
Váš názor tiež Autor projektu Musl, ktorý sa snažil argumentovať, prečo sú návrh Google a zaradenie Libc do distribúcie LLVM veľmi zlé nápady:
- Vyvinúť a udržiavať správnu, kompatibilnú a kvalitnú Libc je veľmi náročná úloha. Problém nie je v množstve kódu, ale v zabezpečení korektného správania a ťažkostiach pri implementácii rozhraní, berúc do úvahy obrovskú vrstvu aplikácií, aké boli kedy napísané v C/C++, ako aj aplikácie v iných jazykoch, ktorých runtime sa používa od Libc. Priamy prístup bez zohľadnenia nuancií povedie iba k tomu, že mnohé existujúce programy nebudú môcť pracovať s Libc, ale potom takýto projekt nebude pre spotrebiteľov zaujímavý.
- Firemný vývoj môže zruinovať Libc, ale presadiť ho na široké použitie, čo vedie k potrebe pridať hacky na zabezpečenie kompatibility v aplikáciách. Vývoj pod záštitou firemného open source projektu bude ťahať deku smerom k potrebám a riešeniam firmy na úkor záujmov komunity. Napríklad, ak identifikujete problém, ktorý je spôsobený chybou v inom programe, v riadenom vývoji je jednoduchšie zabezpečiť, aby Libc bola kompatibilná s touto chybou, než opraviť chybu samotnú. Apple na tieto účely používa BSD libc fork a Google používa musl fork vo Fuchsii. Skúsenosť vývojára musla je taká, že ho kontaktovali najmä právnici, aby si objasnili licenčné problémy, ale nikdy ho nekontaktovali, aby objasnil technické detaily pred vykonaním zbytočných a rušivých zmien vo svojich pobočkách.
- Absencia monokultúry vo vývoji libc a zameranie sa skôr na štandardy riadené konsenzom než na individuálnu kontrolu, čo motivuje vývojárov aplikácií k tomu, aby používali štandardy, než aby boli viazaní na konkrétne implementácie. Preto je autor musl proti zaradeniu svojej knižnice do LLVM, ako aj proti vývoju libc v rámci LLVM, keďže v tomto prípade sa stráca nezávislá povaha libc a určitá implementácia sa stáva prvotriednym riešením pre LLVM a všetky ostatné sa stávajú riešením druhej triedy.
Zdroj: opennet.ru