Google-ko garatzaileetako bat LLVM posta-zerrendan, plataforma anitzeko C liburutegi estandar baten garapenari buruz (Libc) LLVM proiektuaren barruan. Hainbat arrazoirengatik, Google ez dago konforme egungo libc-arekin (glibc, musl) eta konpainia inplementazio berri bat garatzeko bidean da, LLVM-ren baitan garatzea proposatzen dena.
LLVM garapenak Google-ren muntaketa-tresnak eraikitzeko oinarri gisa erabili dira duela gutxi. Ideia nagusia da Google dagoeneko bere libc garatzen hasi bada, zergatik ez berehala bere sistema garatzen LLVMren parte gisa, dagoeneko bere liburutegi estandar propioa eskaintzen baitu C++-rako (Libc++), baina ez du C-rako antzeko liburutegi estandarrik. (libc).
Garapena faseka egitea aurreikusten da, funtzionaltasuna pixkanaka handituz. Lehenengo aukerak aplikazioaren eta Libc sistemaren arteko geruza gisa diseinatzea proposatzen da, eta bertatik oraindik inplementatu ez diren funtzioak maileguan hartuko dira. Funtzionalitate maila jakin batera iritsi ondoren, Libc berria Libc sistemaren ordezko osoa erabil daiteke. x86-64 arkitektura, Linux eta lotura estatikorako laguntzarekin hasteko asmoa dugu (karga dinamikoa, esteka eta arkitektura osagarriak bigarren mailan ezarriko dira).
Proiektua garapenaren hasierako fasean dago oraindik, baina oinarrizko helburuak zehaztuta daude jada:
- Modulartasuna eta garapena multzo monolitiko bat baino liburutegi pikor bat emateko filosofiaren arabera;
- Lotura estatikorako euskarria moduetan (Posiziotik independenteak diren exekutagarriak) eta PIErik gabe. CRT (C exekuzio-denbora) eta PIE kargatzailea eskaintzea estatikoki lotuta dauden exekutagarrietarako;
- C liburutegi-funtzio estandar gehienentzako euskarria, POSIX gehigarriekin eta lehendik dauden aplikazioek eskatzen dituzten sistemarako berariazko luzapen batzuekin;
- Kontuz saltzaileen berariazko luzapenekin eta gehitu behar denean bakarrik. Hirugarrenen luzapenetarako laguntzari dagokionez, Clang eta libc++ proiektuen ikuspegia erabiltzea proposatzen da;
- Garapenean praktika onak erabiltzea LLVM tresna-kit erabiliz, esate baterako, desinfektatzailea eta fuzz probak erabiltzea hasiera-hasieratik.
LLVM garatzaile aktiboetako bat Argi dago zentzuzkoa dela libc LLVM tresna-kitaren zati gisa bidaltzea, baina normalean, behar hori sortzen denean, musl liburutegia erabiltzen dute, ondo idatzita dagoena, hainbat arkitektura onartzen duena eta beharrezko funtzionaltasuna eskaintzen duena, dinamikoentzako euskarria barne. lotuz. Justifikatu daiteke musl LLVM-n txertatzea eta proiektu nagusiarekin sinkronizatutako fork gisa garatzea.
Zure iritzia ere Musl proiektuaren egilea, Googleren proposamena eta Libc LLVM banaketan sartzea zergatik diren oso ideia txarrak argudiatzen saiatu zen:
- Libc zuzena, bateragarria eta kalitate handikoa garatzea eta mantentzea oso lan zaila da. Arazoa ez dago kode kopuruan, baizik eta interfazeak ezartzeko portaera zuzena eta zailtasunak ziurtatzean, inoiz C/C++-n idatzitako aplikazioen geruza erraldoia kontuan hartuta, baita beste hizkuntza batzuetako aplikazioak ere, zeinen exekuzio denbora erabiltzen baita. Libc-en eskutik. Γabardurak kontuan hartu gabe hurbilketa zuzenak lehendik dauden programa askok Libc-ekin funtzionatuko ez dutela bakarrik ekarriko du, baina orduan horrelako proiektu bat ez da kontsumitzaileentzat interesgarria izango.
- Garapen korporatiboak Libc hondatu dezake, baina hedatu den erabilerara bultzatu, eta ondorioz hack-ak gehitu beharra dago aplikazioetan bateragarritasuna bermatzeko. Kode irekiko proiektu korporatibo baten babespean garatzeak konpainiaren behar eta irtenbideetara eramango du manta, komunitatearen interesen kaltetan. Adibidez, beste programa batean akats batek eragindako arazo bat identifikatzen baduzu, garapen kontrolatuan errazagoa da Libc akats honekin bateragarria dela ziurtatzea akatsa bera konpontzea baino. Applek BSD libc fork-a erabiltzen du helburu horietarako, eta Google-k musl fork-a erabiltzen du Fuchsia-n. Musl garatzailearen esperientzia da batez ere abokatuekin harremanetan jarri zela lizentzia-arazoak argitzeko, baina ez zen inoiz harremanetan jarri xehetasun teknikoak argitzeko bere sukurtsaletan aldaketa alferrikako eta kaltegarriak egin aurretik.
- Libc garapenean monolaborantzarik ez izatea eta adostasun-arauetan oinarritutako kontrol indibidualetan baino, eta horrek aplikazioen garatzaileak estandarrak erabiltzera bultzatzen ditu inplementazio zehatzetara lotu beharrean. Horregatik, musl-en egilea bere liburutegia LLVMn sartzearen aurka dago, baita LLVM barruan libc-aren garapenaren aurka ere, kasu honetan libc-en izaera independentea galtzen baita eta inplementazio jakin bat lehen mailako soluzio bilakatzen baita. LLVM eta beste guztiak bigarren mailako soluzio bihurtzen dira.
Iturria: opennet.ru