Unu el la programistoj de Google en la dissendolisto de LLVM pri la evoluo de plurplatforma norma C-biblioteko (Libc) kiel parto de la LLVM-projekto. Pro kelkaj kialoj, Guglo ne estas kontenta pri la nuna libc (glibc, musl) kaj la firmao estas survoje al evoluigo de nova efektivigo, kiu estas proponita esti evoluigita kiel parto de LLVM.
LLVM-evoluoj ĵus estis utiligitaj kiel la bazo por konstruado de la kunigiloj de Google. La ĉefa ideo estas, ke se Guglo jam komencis evoluigi sian libc, kial ne tuj disvolvi sian sistemon kadre de LLVM, kiu jam ofertas sian propran norman bibliotekon por C++ (Libc++), sed ne havas similan norman bibliotekon por C. (libc).
Disvolviĝo estas planita esti efektivigita en stadioj, iom post iom pliigante funkciecon. La unuaj opcioj estas proponitaj por esti desegnitaj kiel tavolo inter la aplikaĵo kaj la sistemo Libc, de kiu funkcioj kiuj ankoraŭ ne estis efektivigitaj estos pruntitaj. Post atingi certan nivelon de funkcieco, la nova Libc povas esti uzata kiel kompleta anstataŭaĵo por la sistemo Libc. Ni planas komenci kun subteno por x86-64-arkitekturo, Linukso, kaj senmova ligado (dinamika ŝarĝo, ligado kaj pliaj arkitekturoj estos efektivigitaj sekundare).
La projekto ankoraŭ estas en la komenca stadio de evoluo, sed bazaj celoj jam estas difinitaj:
- Modulareco kaj evoluo laŭ la filozofio de liverado de grajneca biblioteko prefere ol monolita aro;
- Subteno por statika ligo en reĝimoj (Pozicio-sendependaj ruleblaj) kaj sen PIE. Provizante CRT (C rultempo) kaj PIE-ŝargilon por statike ligitaj ruligeblaj;
- Subteno por la plej multaj el la normaj C-bibliotekfunkcioj, kun POSIX-aldonoj kaj kelkaj sistem-specifaj etendaĵoj postulitaj per ekzistantaj aplikoj;
- Atentu kun vendospecifaj etendaĵoj kaj aldonu ilin nur kiam necese. Koncerne subtenon por triaj etendaĵoj, oni proponas uzi la aliron de la projektoj Clang kaj libc++;
- Uzante plej bonajn praktikojn en evoluo uzante la ilaron de LLVM, kiel uzi sanitigilon kaj fuzz-testadon de la komenco.
Unu el la aktivaj LLVM-programistoj Estas klare, ke havas sencon sendi libc kiel parton de la ilaro LLVM, sed kutime, kiam tia bezono aperas, ili uzas la musl-bibliotekon, kiu estas bone verkita, subtenas diversajn arkitekturojn kaj provizas la necesajn funkciojn, inkluzive de subteno por dinamika. ligado. Povas esti pravigite enigi musl en LLVM kaj evoluigi ĝin kiel forko sinkronigita kun la ĉefa projekto.
Via opinio ankaŭ La aŭtoro de la projekto Musl, kiu provis argumenti, kial la propono de Guglo kaj la inkludo de Libc en la LLVM-distribuo estas tre malbonaj ideoj:
- Disvolvi kaj konservi ĝustan, kongruan kaj altkvalitan Libc estas tre malfacila tasko. La problemo ne estas en la kvanto de kodo, sed en certigi ĝustan konduton kaj malfacilaĵojn en efektivigado de interfacoj, konsiderante la grandegan tavolon de aplikaĵoj iam skribitaj en C/C++, same kiel aplikojn en aliaj lingvoj, kies rultempo estas uzata. de Libc. Fronta aliro sen konsideri la nuancojn nur kondukos al la fakto, ke multaj ekzistantaj programoj ne povos funkcii kun Libc, sed tiam tia projekto ne interesos konsumantojn.
- Korporacia evoluo povas ruinigi Libc, sed puŝi ĝin por ĝeneraligita uzo, rezultigante la bezonon aldoni hakojn por certigi kongruecon en aplikoj. Disvolviĝo sub la aŭspicioj de kompania malfermfonteca projekto tiros la kovrilon al la bezonoj kaj solvoj de la firmao, malprofite de la interesoj de la komunumo. Ekzemple, se vi identigas problemon, kiu estas kaŭzita de cimo en alia programo, en kontrolita evoluo estas pli facile certigi, ke Libc estas kongrua kun ĉi tiu cimo ol ripari la cimon mem. Apple uzas la BSD-libc-forkon por ĉi tiuj celoj, kaj Guglo uzas la musl-forkon en Fuchsia. La sperto de la musl-programisto estas, ke li estis kontaktita ĉefe de advokatoj por klarigi licencajn aferojn, sed neniam estis kontaktita por klarigi teknikajn detalojn antaŭ fari senutilajn kaj interrompajn ŝanĝojn al siaj branĉoj.
- La foresto de monokulturo en libc-evoluo kaj fokuso sur konsent-movitaj normoj prefere ol individua kontrolo, kiu instigas aplikiĝprogramistojn uzi normojn prefere ol esti ligita al specifaj efektivigoj. Tial la verkinto de musl estas kontraŭ la inkludo de sia biblioteko en LLVM, same kiel kontraŭ la evoluo de libc ene de LLVM, ĉar en ĉi tiu kazo la sendependa naturo de libc estas perdita kaj certa efektivigo iĝas unuaklasa solvo por LLVM, kaj ĉiuj aliaj fariĝas duaklasa solvo.
fonto: opennet.ru