Üks Google'i arendajatest LLVM postitusloendis üles arutelu mitmeplatvormilise standardse C teeki (Libc) arendamisest LLVM projekti raames. Mitme põhjuse tõttu ei sobi Google'ile praegused libc (glibc, musl) ning ettevõte on teel uue rakenduse arendamise suunas, mida plaanitakse arendada LLVM osana.
Viimastel aegadel on LLVM arendus olnud Google'i koostööriistade ehitamise aluseks. Peamine idee on see, et kui Google on juba alustanud oma libc arendamist, siis miks mitte arendada kohe oma süsteemi LLVM raames, mis juba pakub oma standardteeki C++ (Libc++) jaoks, kuid ei oma sarnast standardteeki C jaoks (Libc).
Arendamine toimub järk-järgult, funktsionaalsust järk-järgult suurendades. Esimesi variante on plaanis vormistada rakenduse ja süsteemi Libc vaheliseks kihiks, millest laenatakse veel teostamata võimalusi. Pärast teatud funktsionaalsuse taseme saavutamist saab uus Libc täielikult asendada süsteemi Libc. Alustatakse x86-64 arhitektuuri, Linuxi ja staatilise linkimise toega (dünaamiline laadimine, sidumine ja täiendavad arhitektuurid realiseeritakse teises etapis).
Projekt on alles arendamise algusjärgus, kuid põhieesmärgid on juba määratletud:
- Modulaarsus ja areng kooskõlas graanulraamatukogu tarnimise filosoofiaga, mitte monoliitse komplektiga;
- Toetamine staatilise linkimise režiimides, (Position-independent executables) ja ilma PIE-ta. CRT (C runtime) ja PIE laadija pakkumine staatiliselt lingitud täidetavatele failidele;
- Enamiku tavalise C-teegi funktsioonide toetamine koos POSIX-i täiustuste ja mõningate süsteemselt spetsiifiliste laiendustega, mis on nõutud olemasolevates rakendustes;
- Tootlik suhtumine tootjate spetsiifilistesse laiendustesse ja nende lisamine ainult vajaduse korral. Kolmandate osapoolte laienduste toetuse osas on soovitatav rakendada Clangi ja libc++ projekti lähenemist.
- Parimate praktika rakendamine arenduses LLVM tööriistadega, nagu sanitizeri ja fuzzing-testimise kasutamine algusest peale.
Üks aktiivsetest LLVM arendajatest , et libc tarnimine LLVM tööriistade komplektis ei ole mõttetu, kuid tavaliselt sellise vajaduse korral kasutatakse musl raamatukogu, mis on kvaliteetselt kirjutatud, toetab erinevaid arhitektuure ja pakub vajalikku funktsionaalsust, sealhulgas toetab dünaamilist linkimist. Musli integreerimine LLVM-i ja selle arendamine võib olla põhjendatud kui sünkroniseeritud põhiprojekti fork.
Samuti Musl projekti autor, kes üritas põhjendada, miks Google'i ettepanek ja Libc kaasamine LLVM-i tarnesse on väga halvad ideed:
- Korraliku, ühilduva ja kvaliteetse Libc arendamine ja toetamine on äärmiselt keeruline ülesanne. Probleem ei seisne koodi mahus, vaid õige käitumise tagamises ja liideste rakendamise raskustes, arvestades tohutut hulka varem kirjutatud rakendusi C/C++-s ja teistes keeltes, mille runtime kasutab Libc. Üks-dimensionalne lähenemine, mis ei arvestada nüansse, viib selleni, et paljud olemasolevad programmid ei saa Libc-ga töötada, kuid siis ei ole selline projekt tarbijatele huvitav.
- Ettevõtte arendamine võib Libci rikkuda, kuid edendada laiemat kasutust, mille tulemuseks on vajadus lisahaakide lisamiseks rakenduste ühilduvuse tagamiseks. Ettevõtte avatud projekti raames toimuva arenduse korralikud vajadused ja lahendused tõukavad sageli populaarsete avatud allikate huvidest mööda. Näiteks probleemi ilmnemisel, mis on põhjustatud vigadest teises programmis, on kontrollitava arenduse puhul lihtsam tagada Libci ühilduvus selle vea järele, kui parandada ise viga. Apple kasutab selleks BSD libc haru, samas kui Google rakendab Fuchsias musl haru. Musli arendaja kogemus näitab, et temaga on peamiselt suhtlenud juristid, et täpsustada litsentsimise küsimusi, kuid kunagi ei pöördutud tehniliste detailide täpsustamiseks, enne kui nad tegid oma harudesse kasutu ja toimimist rikkumise muudatusi.
- Monokultuuri puudumine libc arendamisel ja keskendumine konsensusele põhinevatele standarditele, mitte ühekülgsele juhtimisele motiveerib rakenduste arendajaid kasutama standardeid, mitte siduma ennast konkreetsete rakendustega. Just seetõttu on musl autori arvates tema raamatukogu lisamine LLVM-i vastu, samuti libc arendamine LLVM raames, kuna sel juhul kaob libc iseseisvus ning konkreetne rakendus muutub LLVM-i esimese klassi lahenduseks, samas kui kõik teised jäävad teise klassi lahendusteks.
Allikas: opennet.ru
