Salah sahiji pamekar ti Google dina milis LLVM ngeunaan ngembangkeun perpustakaan C standar multi-platform (Libc) salaku bagian tina proyék LLVM. Pikeun sababaraha alesan, Google henteu puas ku libc ayeuna (glibc, musl) sareng perusahaan nuju nuju ngembangkeun palaksanaan énggal, anu diusulkeun pikeun dikembangkeun salaku bagian tina LLVM.
Kamajuan LLVM nembe dianggo salaku dasar pikeun ngawangun alat-alat perakitan Google. Gagasan utama nyaéta upami Google parantos ngamimitian ngembangkeun libc na, naha henteu langsung ngembangkeun sistemna salaku bagian tina LLVM, anu parantos nawiskeun perpustakaan standar sorangan pikeun C++ (Libc++), tapi henteu gaduh perpustakaan standar anu sami pikeun C. (libc).
Pangwangunan rencanana dilaksanakeun sacara bertahap, laun-laun ningkatkeun fungsionalitas. Pilihan kahiji diusulkeun pikeun dirarancang salaku lapisan antara aplikasi sareng sistem Libc, dimana fitur anu henteu acan dilaksanakeun bakal diinjeum. Saatos ngahontal tingkat fungsionalitas anu tangtu, Libc énggal tiasa dianggo salaku gaganti lengkep pikeun sistem Libc. Kami ngarencanakeun mimitian ku dukungan pikeun arsitéktur x86-64, Linux, sareng tautan statik (muatan dinamis, tautan, sareng arsitéktur tambahan bakal dilaksanakeun kadua).
Proyék masih dina tahap awal pangwangunan, tapi tujuan dasar parantos ditetepkeun:
- Modularity sarta ngembangkeun luyu jeung falsafah delivering perpustakaan granular tinimbang susunan monolithic;
- Rojongan pikeun linking statik dina modeu (Executables posisi-bebas) jeung tanpa PIE. Nyadiakeun CRT (C runtime) jeung PIE loader pikeun executables numbu statis;
- Rojongan pikeun sabagéan ageung fungsi perpustakaan C standar, kalayan tambahan POSIX sareng sababaraha ekstensi khusus sistem anu diperyogikeun ku aplikasi anu tos aya;
- Ati-ati sareng ekstensi spésifik vendor sareng ukur tambahkeun upami diperyogikeun. Ngeunaan dukungan pikeun ekstensi pihak katilu, diusulkeun pikeun ngagunakeun pendekatan Clang sareng libc ++ proyék;
- Nganggo prakték pangsaéna dina pamekaran nganggo toolkit LLVM, sapertos nganggo sanitizer sareng uji fuzz ti mimiti.
Salah sahiji pamekar LLVM aktip Ieu jelas yén asup akal pikeun ngirim libc salaku bagian tina toolkit LLVM, tapi biasana, nalika kabutuhan sapertos timbul, aranjeunna nganggo perpustakaan musl, anu ditulis ogé, ngarojong rupa arsitéktur, sarta nyadiakeun fungsionalitas diperlukeun, kaasup rojongan pikeun dinamis. ngaitkeun. Bisa jadi diyakinkeun pikeun embed musl kana LLVM sarta ngamekarkeun salaku garpu disingkronkeun jeung proyék utama.
Pendapat anjeun ogé Panulis proyék Musl, anu nyobian ngabantah naha usulan Google sareng kalebet Libc dina distribusi LLVM mangrupikeun ide anu goréng:
- Ngembangkeun sareng ngajaga Libc anu leres, cocog sareng kualitas luhur mangrupikeun tugas anu sesah. Masalahna sanés dina jumlah kode, tapi pikeun mastikeun paripolah anu leres sareng kasusah dina ngalaksanakeun antarmuka, kalayan nganggap lapisan ageung aplikasi anu kantos ditulis dina C / C ++, ogé aplikasi dina basa sanés, waktos runtime dianggo. ku Libc. Hiji pendekatan sirah-on tanpa tumut kana akun nuances ngan bakal ngakibatkeun kanyataan yén loba program aya moal bisa digawekeun ku Libc, tapi lajeng proyék misalna hiji moal dipikaresep ku konsumén.
- Pangwangunan perusahaan tiasa ngarusak Libc, tapi nyorong pikeun dianggo sacara umum, nyababkeun kabutuhan pikeun nambihan hacks pikeun mastikeun kasaluyuan dina aplikasi. Pangwangunan di handapeun naungan proyék open source perusahaan bakal narik simbut kana kabutuhan sareng solusi perusahaan, anu ngarugikeun kapentingan masarakat. Contona, upami anjeun ngaidentipikasi masalah anu disababkeun ku bug dina program sejen, dina ngembangkeun dikawasa leuwih gampang pikeun mastikeun yén Libc kompatibel jeung bug ieu ti ngalereskeun bug sorangan. Apple nganggo garpu libc BSD pikeun tujuan ieu, sareng Google nganggo garpu musl di Fuchsia. Pangalaman pamekar musl nyaéta yén anjeunna dikontak utamina ku pengacara pikeun netelakeun masalah lisénsi, tapi henteu pernah dikontak pikeun netelakeun detil téknis sateuacan ngadamel parobihan anu teu aya gunana sareng ngaganggu kana cabangna.
- Henteuna monoculture dina ngembangkeun libc sarta fokus kana standar konsensus-disetir tinimbang kontrol individu, nu motivates pamekar aplikasi ngagunakeun standar tinimbang dihijikeun ka implementations husus. Éta pisan sababna naha panulis musl ngalawan citakan perpustakaan na di LLVM, kitu ogé ngalawan ngembangkeun libc dina LLVM, saprak dina hal ieu alam bebas libc leungit sarta palaksanaan tangtu janten solusi kelas munggaran pikeun LLVM, sareng anu sanésna janten solusi kelas kadua.
sumber: opennet.ru