Üks Google'i arendajatest LLVM-i meililistis teema, mis puudutab mitme platvormi standardse C-raamatukogu (Libc) arendamist LLVM-i projekti raames. Mitmel põhjusel ei rahulda Google'i praegused libc (glibc, musl) ning ettevõte on teel uue teostuse väljatöötamise suunas, mida pakutakse arendada osana LLVM-ist.
Viimastel aegadel kasutatakse LLVM-i arengut Google'i koostamisriistade aluseks. Peamine idee on see, et kui Google on juba hakanud oma libc-d arendama, siis miks mitte kohe arendada oma süsteemi LLVM-is, mis pakub juba oma standardraamatukogu C++ jaoks (Libc++), kuid ei oma sarnast standardset raamatukogu C jaoks (Libc).
Arendust kavandatakse järk-järgult, funktsionaalsuse järkjärgulise suurendamisega. Esimesed variandid soovitatakse vormistada vahekihtina rakenduse ja süsteemi Libc vahel, millest saab laenata veel rakendamata võimalusi. Pärast teatud funktsionaalsuse taseme saavutamist saab uus Libc olla süsteemi Libc täielik asendaja. Alustatakse x86-64, Linuxi ja staatilise linkimise toega (dünaamiline laadimine, kompositsioon ja täiendavad arhitektuurid viiakse ellu teises etapis).
Projekt on praegu algstaadiumis, kuid põhieesmärgid on juba määratletud:
- Modulaarsus ja areng vastavalt graanuliseeritud raamatukogu tarnimise filosoofiale, mitte monoliitsete komplektide kogumile;
- Toe pakkumine staatilisele linkimisele režiimides (Position-independent executables) ja ilma PIE-ta. CRT (C jooksutegur) ja PIE laadija pakkumine staatiliselt lingitud täidetavatele failidele;
- Enamiku standardse C-raamatukogu funktsioonide toetamine koos POSIX-i täiendustega ja mõningate süsteemispetsiifiliste laiendustega, mis on nõudlikud olemasolevates rakendustes;
- Ettevaatlik lähenemine tootjate spetsiifilistele laiendustele ning nende lisamine ainult vajadusel. Kolmandate osapoolte laienduste toetamises soovitatakse rakendada Clangi ja libc+ lähenemist;
- Parimate praktikate kasutamine arenduses, kasutades LLVM-i tööriistu, nagu sanitiseerijate ja fuzzing-testimise rakendamine alates algusest.
Üks LLVM aktiivsetest arendajatest , et libc pakkumine LLVM tööriistakogus ei ole mõttetu, kuid tavaliselt kasutatakse sellise vajaduse korral musl raamatukogu, mis on kvaliteetselt kirjutatud, toetab erinevaid arhitektuure ja pakub vajalikku funktsionaalsust, sealhulgas dünaamilist sidumist. Musli integreerimine LLVM-i ja selle arendamine kooskõlas peamise projektiga võib olla põhjendatud.
Oma arvamuse Musl projekti autor, kes püüdis põhjendada, miks Google'i ettepanek ja libc kaasamine LLVM-i on väga halvad ideed:
- Õige, ühilduva ja kvaliteetse Libc arendamine ja hooldamine on väga keeruline ülesanne. Probleem ei ole koodimahtudes, vaid õige toimimise tagamises ning liidestega seotud raskustes, arvestades tohutut hulka kunagi kirjutatud rakendusi C/C++-s ja rakendusi teistes keeltes, mille runtime kasutab Libc-d. Üksikud lähenemised, ilma nüansse arvesse võtmata, toovad kaasa selle, et paljud olemasolevad programmid ei suuda Libc-d kasutada, kuid siis ei oleks selline projekt tarbijatele huvitav.
- Ettevõtte arendus võib Libc-d rikku, kuid sundida seda laialdasemaks kasutamiseks, mille tulemuseks on vajadus lisada hacke rakenduste ühilduvuse tagamiseks. Ettevõtte avatud projekti all arendamine tõmbab tekkide tõmbamise vajadusi ja lahendusi ettevõtte poole, kahjustades kogukonna huve. Näiteks, kui ilmneb probleem, mis on põhjustatud veast muus oma programmis, on kontrollitud arenduses lihtsam tagada Libc ühilduvust selle vea suhtes, kui vea ennast parandada. Apple kasutab selleks BSD libc forki, Google aga rakendab Fuchsia-s musl forki. Musli arendaja kogemus näitab, et temaga on peamiselt suhelnud juristid, et selgitada litsentsiküsimusi, kuid tehniliste detailide täpsustamiseks ei ole kunagi pöördutud enne, kui nad on oma harudesse teinud kasutuid ja töökorraldust rikkuvaid muudatusi.
- Monokultuuri puudumine libc arendamisel ja suunatus konsensusele põhinevatele standarditele, mitte ainuisikuliselt juhtimisele, motiveerib rakenduste arendajaid kasutama standardeid ega siduma end konkreetsete rakendustega. Just seetõttu on autori musl vastu selle teegi lisamisele LLVM-i koosseisu ja libc arendamisele LLVM-i raames, kuna sellisel juhul kaob libc sõltumatu iseloom ja konkreetne rakendus muutub LLVM-i jaoks esmaklassiliseks lahenduseks, samas kui kõik teised jäävad teise klassi.
Allikas: opennet.ru
