Ee vun den Entwéckler vu Google op der LLVM Mailing Lëscht iwwer d'Entwécklung vun enger Multi-Plattform Standard C Bibliothéik (Libc) am Kader vum LLVM Projet. Aus e puer Grënn ass Google net zefridden mat der aktueller libc (glibc, musl) an d'Firma ass um Wee fir eng nei Implementatioun z'entwéckelen, déi proposéiert gëtt als Deel vum LLVM entwéckelt ze ginn.
LLVM Entwécklungen goufen viru kuerzem als Basis benotzt fir d'Versammlungsinstrumenter vu Google ze bauen. D'Haaptidee ass datt wann Google schonn ugefaang huet seng libc z'entwéckelen, firwat net direkt säi System als Deel vum LLVM entwéckelen, dee scho seng eege Standardbibliothéik fir C++ (Libc++) bitt, awer keng ähnlech Standardbibliothéik fir C huet (libc).
Entwécklung ass geplangt an Etappen duerchgefouert ze ginn, graduell Erhéijung vun der Funktionalitéit. Déi éischt Optioune ginn proposéiert als Layer tëscht der Applikatioun an dem System Libc entworf ze ginn, aus deenen d'Features, déi nach net ëmgesat goufen, ausgeléint ginn. Nodeems Dir e gewëssen Niveau vun der Funktionalitéit erreecht hutt, kann den neie Libc als komplette Ersatz fir de System Libc benotzt ginn. Mir plangen mat Ënnerstëtzung fir x86-64 Architektur, Linux a statesch Verknëppung unzefänken (dynamesch Luede, Verknëppung an zousätzlech Architekturen ginn sekundär ëmgesat).
De Projet ass nach ëmmer an der éischter Etapp vun der Entwécklung, awer d'Basisziler si scho definéiert:
- Modularitéit an Entwécklung am Aklang mat der Philosophie fir eng granulär Bibliothéik ze liwweren anstatt e monolithesche Set;
- Ënnerstëtzung fir statesch Verknëppung a Modi mat (Positiounsonofhängeg ausführbar) an ouni PIE. Bitt CRT (C Runtime) a PIE Loader fir statesch verlinkte Ausführbaren;
- Ënnerstëtzung fir déi meescht vun de Standard C Bibliothéik Funktiounen, mat POSIX Ergänzunge an e puer systemspezifesch Extensiounen erfuerderlech vun existente Uwendungen;
- Sidd virsiichteg mat Verkeefer-spezifeschen Extensiounen a füügt se nëmmen un wann néideg. Wat d'Ënnerstëtzung fir Drëtt-Partei-Extensiounen ugeet, gëtt proposéiert d'Approche vun de Clang- a libc++ Projeten ze benotzen;
- Benotzt bescht Praktiken an der Entwécklung mam LLVM Toolkit, sou wéi d'Benotzung vu Sanitizer a Fuzz Tester vun Ufank un.
Ee vun den aktiven LLVM Entwéckler Et ass kloer datt et Sënn mécht libc als Deel vum LLVM Toolkit ze verschécken, awer normalerweis, wann esou e Bedierfnes entsteet, benotze se d'Musl Bibliothéik, déi gutt geschriwwen ass, ënnerstëtzt verschidde Architekturen, a bitt déi néideg Funktionalitéit, dorënner Ënnerstëtzung fir dynamesch verlinkt. Et kann gerechtfäerdegt sinn Musl an LLVM z'integréieren an et als Gabel z'entwéckelen, synchroniséiert mam Haaptprojet.
Är Meenung och Den Auteur vum Musl-Projet, dee probéiert huet ze argumentéieren firwat d'Propositioun vu Google an d'Inklusioun vu Libc an der LLVM Verdeelung ganz schlecht Iddien sinn:
- Eng korrekt, kompatibel a qualitativ héichwäerteg Libc z'entwéckelen an z'erhalen ass eng ganz schwéier Aufgab. De Problem ass net an der Quantitéit vum Code, mee am korrekt Verhalen a Schwieregkeete bei der Ëmsetzung vun Interfaces ze garantéieren, andeems Dir déi rieseg Schicht vun Uwendungen berücksichtegt, déi jeemools an C/C++ geschriwwe goufen, souwéi Uwendungen an anere Sproochen, déi d'Runtime benotzt gëtt vum Libc. Eng direkt Approche ouni d'Nuancen ze berücksichtegen wäert nëmmen zu der Tatsaach féieren datt vill existent Programmer net fäeg sinn mat Libc ze schaffen, awer sou e Projet wäert d'Konsumenten net interesséieren.
- Firmenentwécklung kann Libc ruinéieren, awer dréckt et fir verbreet Benotzung, wat zu der Bedierfnes fir Hacks ze addéieren fir Kompatibilitéit an Uwendungen ze garantéieren. D'Entwécklung ënner der Aféierung vun engem Firmen Open Source Projet wäert d'Decken op d'Bedierfnesser a Léisunge vun der Firma zéien, zum Nodeel vun den Interesse vun der Gemeinschaft. Zum Beispill, wann Dir e Problem identifizéiert deen duerch e Feeler an engem anere Programm verursaacht gëtt, ass et a kontrolléierter Entwécklung méi einfach ze garantéieren datt Libc mat dësem Feeler kompatibel ass wéi de Feeler selwer ze fixéieren. Apple benotzt d'BSD libc Gabel fir dës Zwecker, a Google benotzt d'Musl Gabel a Fuchsia. D'Erfahrung vum Musl Entwéckler ass datt hien haaptsächlech vun Affekote kontaktéiert gouf fir Lizenzprobleemer ze klären, awer ni kontaktéiert gouf fir technesch Detailer ze klären ier nëtzlos an disruptiv Ännerungen a senge Filialen gemaach goufen.
- D'Feele vun enger Monokultur an der libc Entwécklung an e Fokus op Konsens-Undriff Standarden anstatt eleng Kontroll, wat Applikatioun Entwéckler motivéiert Standarden ze benotzen anstatt mat spezifeschen Implementatiounen gebonne ginn. Dofir ass den Auteur vu musl géint d'Inklusioun vu senger Bibliothéik am LLVM, wéi och géint d'Entwécklung vu libc bannent LLVM, well an dësem Fall ass d'onofhängeg Natur vum libc verluer an eng gewëssen Ëmsetzung gëtt eng éischtklasseg Léisung fir LLVM, an all déi aner ginn eng zweetklasseg Léisung.
Source: opennet.ru