Ien fan 'e ûntwikkelders fan Google op 'e LLVM-mailinglist oer de ûntwikkeling fan in multi-platfoarm standert C-bibleteek (Libc) as ûnderdiel fan it LLVM-projekt. Om in oantal redenen is Google net tefreden mei de hjoeddeistige libc (glibc, musl) en it bedriuw is op 'e wei nei it ûntwikkeljen fan in nije ymplemintaasje, dy't foarsteld wurdt om te ûntwikkeljen as ûnderdiel fan LLVM.
LLVM-ûntwikkelingen binne koartlyn brûkt as basis foar it bouwen fan Google's assemblage-ark. It haadidee is dat as Google al begon is mei it ûntwikkeljen fan syn libc, wêrom dan net fuortendaliks syn systeem ûntwikkelje as ûnderdiel fan LLVM, dy't al in eigen standertbibleteek foar C++ (Libc++) biedt, mar gjin ferlykbere standertbibleteek foar C hat. (libc).
Untwikkeling is pland om stadichoan te fieren, stadichoan tanimmende funksjonaliteit. De earste opsjes wurde foarsteld om te wurde ûntwurpen as in laach tusken de applikaasje en it systeem Libc, wêrfan funksjes dy't noch net binne ymplementearre wurde liend. Nei it berikken fan in bepaald nivo fan funksjonaliteit, kin de nije Libc brûkt wurde as in folsleine ferfanging foar it systeem Libc. Wy binne fan plan om te begjinnen mei stipe foar x86-64-arsjitektuer, Linux, en statyske keppeling (dynamysk laden, keppeljen en ekstra arsjitektuer sille sekondêr wurde ymplementearre).
It projekt is noch yn 'e earste faze fan ûntwikkeling, mar basisdoelen binne al definiearre:
- Modulariteit en ûntwikkeling yn oerienstimming mei de filosofy fan it leverjen fan in korrelige bibleteek ynstee fan in monolityske set;
- Stipe foar statyske keppeling yn modi (Posysje-ûnôfhinklike executables) en sûnder PIE. It leverjen fan CRT (C runtime) en PIE-loader foar statysk keppele útfierbere;
- Stipe foar de measte fan 'e standert C-bibleteekfunksjes, mei POSIX-tafoegings en guon systeemspesifike tafoegings nedich troch besteande applikaasjes;
- Wês foarsichtich mei ferkeaperspesifike tafoegings en foegje se allinich ta as it nedich is. Oangeande stipe foar útwreidingen fan tredden, wurdt foarsteld om de oanpak fan 'e Clang- en libc++-projekten te brûken;
- Gebrûk fan bêste praktiken yn ûntwikkeling mei de LLVM toolkit, lykas it brûken fan sanitizer en fuzztesten fan it begjin ôf.
Ien fan 'e aktive LLVM-ûntwikkelders It is dúdlik dat it sin hat om libc te ferstjoeren as ûnderdiel fan 'e LLVM-ark, mar meastal, as sa'n need ûntstiet, brûke se de musl-bibleteek, dy't goed skreaun is, ferskate arsjitektueren stipet en de nedige funksjonaliteit leveret, ynklusyf stipe foar dynamysk keppeljen. It kin rjochtfeardich wêze om musl yn LLVM yn te foegjen en it te ûntwikkeljen as in foarke syngronisearre mei it haadprojekt.
Jo miening ek De skriuwer fan it Musl-projekt, dy't besocht te argumintearjen wêrom't Google's foarstel en it opnimmen fan Libc yn 'e LLVM-distribúsje heul minne ideeën binne:
- It ûntwikkeljen en ûnderhâlden fan in korrekte, kompatibele en heechweardige Libc is in heul lestige taak. It probleem is net yn 'e hoemannichte koade, mar yn it garandearjen fan korrekt gedrach en swierrichheden by it ymplementearjen fan ynterfaces, rekken hâldend mei de enoarme laach applikaasjes ea skreaun yn C/C++, lykas applikaasjes yn oare talen, wêrfan de runtime wurdt brûkt by Libc. In direkte oanpak sûnder rekken te hâlden mei de nuânses sil allinich liede ta it feit dat in protte besteande programma's net mei Libc wurkje kinne, mar dan sil sa'n projekt net fan belang wêze foar konsuminten.
- Bedriuwsûntwikkeling kin Libc ferneatigje, mar triuwe it foar wiidferspraat gebrûk, wat resulteart yn 'e needsaak om hacks ta te foegjen om kompatibiliteit yn applikaasjes te garandearjen. Untwikkeling ûnder auspysjes fan in bedriuw iepen boarne projekt sil de tekken lûke nei de behoeften en oplossingen fan it bedriuw, yn it neidiel fan 'e belangen fan' e mienskip. As jo bygelyks in probleem identifisearje dat wurdt feroarsake troch in brek yn in oar programma, yn kontrolearre ûntwikkeling is it makliker om te soargjen dat Libc kompatibel is mei dizze brek dan om de brek sels te reparearjen. Apple brûkt de BSD libc-gabel foar dizze doelen, en Google brûkt de musl-gabel yn Fuchsia. De ûnderfining fan 'e musl-ûntwikkelder is dat hy foaral kontakt opnommen waard troch advokaten om fergunningproblemen te ferdúdlikjen, mar waard nea kontakt opnommen om technyske details te ferdúdlikjen foardat hy nutteleaze en fersteurende feroarings makke oan syn tûken.
- It ûntbrekken fan in monokultuer yn libc-ûntwikkeling en in fokus op konsensus-oandreaune noarmen ynstee fan yndividuele kontrôle, dy't applikaasje-ûntwikkelders motivearret om noarmen te brûken ynstee fan bûn oan spesifike ymplemintaasjes. Dêrom is de skriuwer fan musl tsjin it opnimmen fan syn bibleteek yn LLVM, en ek tsjin de ûntwikkeling fan libc binnen LLVM, om't yn dit gefal it selsstannige karakter fan libc ferlern giet en in bepaalde ymplemintaasje in earste-klasse oplossing wurdt foar LLVM, en alle oaren wurde in twadde klasse oplossing.
Boarne: opennet.ru