Salah satu pembangun daripada Google pada senarai mel LLVM tentang pembangunan perpustakaan C standard berbilang platform (Libc) sebagai sebahagian daripada projek LLVM. Atas beberapa sebab, Google tidak berpuas hati dengan libc semasa (glibc, musl) dan syarikat sedang dalam perjalanan untuk membangunkan pelaksanaan baharu, yang dicadangkan untuk dibangunkan sebagai sebahagian daripada LLVM.
Perkembangan LLVM baru-baru ini telah digunakan sebagai asas untuk membina alatan pemasangan Google. Idea utama ialah jika Google telah mula membangunkan libcnya, maka mengapa tidak segera membangunkan sistemnya sebagai sebahagian daripada LLVM, yang sudah menawarkan perpustakaan standardnya sendiri untuk C++ (Libc++), tetapi tidak mempunyai perpustakaan standard yang serupa untuk C ( libc).
Pembangunan dirancang untuk dijalankan secara berperingkat, secara beransur-ansur meningkatkan fungsi. Pilihan pertama dicadangkan untuk direka bentuk sebagai lapisan antara aplikasi dan sistem Libc, yang mana ciri-ciri yang belum dilaksanakan akan dipinjam. Selepas mencapai tahap kefungsian tertentu, Libc baharu boleh digunakan sebagai pengganti lengkap untuk sistem Libc. Kami merancang untuk memulakan dengan sokongan untuk seni bina x86-64, Linux dan pemautan statik (pemuatan dinamik, pemautan dan seni bina tambahan akan dilaksanakan secara kedua).
Projek ini masih di peringkat awal pembangunan, tetapi matlamat asas telah ditakrifkan:
- Modulariti dan pembangunan selaras dengan falsafah menyampaikan perpustakaan berbutir dan bukannya set monolitik;
- Sokongan untuk pemautan statik dalam mod (Boleh laku bebas kedudukan) dan tanpa PIE. Menyediakan CRT (masa jalan C) dan pemuat PIE untuk boleh laku terpaut secara statik;
- Sokongan untuk kebanyakan fungsi perpustakaan C standard, dengan tambahan POSIX dan beberapa sambungan khusus sistem yang diperlukan oleh aplikasi sedia ada;
- Berhati-hati dengan sambungan khusus vendor dan hanya tambahkannya apabila perlu. Mengenai sokongan untuk sambungan pihak ketiga, adalah dicadangkan untuk menggunakan pendekatan projek Clang dan libc++;
- Menggunakan amalan terbaik dalam pembangunan menggunakan kit alat LLVM, seperti menggunakan sanitizer dan ujian fuzz dari awal lagi.
Salah satu pembangun LLVM yang aktif Adalah jelas bahawa masuk akal untuk menghantar libc sebagai sebahagian daripada kit alat LLVM, tetapi biasanya, apabila keperluan sedemikian timbul, mereka menggunakan perpustakaan musl, yang ditulis dengan baik, menyokong pelbagai seni bina dan menyediakan fungsi yang diperlukan, termasuk sokongan untuk dinamik. menghubungkan. Ia mungkin wajar untuk membenamkan musl ke dalam LLVM dan membangunkannya sebagai garpu yang disegerakkan dengan projek utama.
Pendapat anda juga Pengarang projek Musl, yang cuba berhujah mengapa cadangan Google dan kemasukan Libc dalam pengedaran LLVM adalah idea yang sangat buruk:
- Membangunkan dan mengekalkan Libc yang betul, serasi dan berkualiti tinggi adalah tugas yang sangat sukar. Masalahnya bukan pada jumlah kod, tetapi dalam memastikan tingkah laku yang betul dan kesukaran dalam melaksanakan antara muka, dengan mengambil kira lapisan besar aplikasi yang pernah ditulis dalam C/C++, serta aplikasi dalam bahasa lain, yang masa jalannya digunakan. oleh Libc. Pendekatan langsung tanpa mengambil kira nuansa hanya akan membawa kepada fakta bahawa banyak program sedia ada tidak akan dapat berfungsi dengan Libc, tetapi projek sedemikian tidak akan menarik minat pengguna.
- Pembangunan korporat boleh merosakkan Libc, tetapi menolaknya untuk kegunaan meluas, menyebabkan keperluan untuk menambah penggodaman untuk memastikan keserasian dalam aplikasi. Pembangunan di bawah naungan projek sumber terbuka korporat akan menarik selimut ke arah keperluan dan penyelesaian syarikat, sehingga menjejaskan kepentingan masyarakat. Contohnya, jika anda mengenal pasti masalah yang disebabkan oleh pepijat dalam program lain, dalam pembangunan terkawal adalah lebih mudah untuk memastikan bahawa Libc serasi dengan pepijat ini daripada membetulkan pepijat itu sendiri. Apple menggunakan garpu libc BSD untuk tujuan ini, dan Google menggunakan garpu musl di Fuchsia. Pengalaman pemaju musl ialah beliau dihubungi terutamanya oleh peguam untuk menjelaskan isu pelesenan, tetapi tidak pernah dihubungi untuk menjelaskan butiran teknikal sebelum membuat perubahan yang tidak berguna dan mengganggu cawangannya.
- Ketiadaan monokultur dalam pembangunan libc dan tumpuan pada piawaian yang dipacu konsensus dan bukannya kawalan individu, yang mendorong pembangun aplikasi untuk menggunakan piawaian dan bukannya terikat pada pelaksanaan tertentu. Itulah sebabnya pengarang musl menentang kemasukan perpustakaannya dalam LLVM, serta menentang pembangunan libc dalam LLVM, kerana dalam kes ini sifat bebas libc hilang dan pelaksanaan tertentu menjadi penyelesaian kelas pertama untuk LLVM, dan semua yang lain menjadi penyelesaian kelas kedua.
Sumber: opennet.ru