Rumah  >  Artikel  >  Operasi dan penyelenggaraan  >  Ketahui tentang Linux ABI dalam sepuluh minit

Ketahui tentang Linux ABI dalam sepuluh minit

WBOY
WBOYke hadapan
2023-08-03 16:33:04984semak imbas

十分钟让你了解 Linux ABI

Terjemahan LCTT: Semalam, AlmaLinux berkata bahawa ia akan menyerah keserasian 1:1 dengan RHEL, tetapi akan mengekalkan keserasian ABI dengan RHEL supaya perisian yang berjalan pada RHEL boleh berjalan dengan lancar pada AlmaLinux. Sesetengah pelajar mungkin tidak begitu jelas tentang konsep ABI, jadi saya menterjemah artikel ini untuk difahami oleh semua orang.

Ramai peminat Linux sudah biasa dengan amaran terkenal Linus Torvalds: "Kami tidak memusnahkan ruang pengguna", tetapi maknanya mungkin tidak jelas kepada semua orang yang mendengarnya.

"Peraturan Pertama" ini mengingatkan pembangun tentang kestabilan Antara Muka Binari Aplikasi (ABI), yang digunakan untuk komunikasi dan konfigurasi antara aplikasi dan kernel. Perkara berikut bertujuan untuk membiasakan pembaca dengan konsep ABI, menerangkan sebab kestabilan ABI penting dan membincangkan perkara yang disertakan dalam ABI stabil Linux. Pertumbuhan dan evolusi Linux yang berterusan memerlukan perubahan pada ABI, beberapa daripadanya telah menjadi kontroversi.

Apa itu ABI?

ABI adalah singkatan dari Applications Binary Interface. Satu cara untuk memahami konsep ABI adalah dengan mempertimbangkan bagaimana ia berbeza daripada konsep lain. Bagi kebanyakan pembangun, Antara Muka Pengaturcaraan Aplikasi (API) lebih biasa. Biasanya, fail pengepala perpustakaan dan dokumentasi dianggap APInya, bersama-sama dengan dokumentasi standard seperti HTML5 . Program yang memanggil pustaka atau bertukar-tukar data dalam format rentetan mesti mematuhi konvensyen yang diterangkan dalam API, jika tidak, anda mungkin mendapat hasil yang tidak dijangka.

ABI adalah serupa dengan API kerana ia menentukan cara arahan ditafsirkan dan data binari ditukar. Untuk program C, ABI lazimnya merangkumi jenis pemulangan dan senarai hujah fungsi, susun atur struktur dan makna, susunan dan skop jenis terbilang. Sehingga 2022, kernel Linux masih hampir keseluruhannya program C dan oleh itu mesti mematuhi spesifikasi ini.

Penerangan tentang "Antaramuka Panggilan Sistem Kernel" boleh didapati dalam "Manual Linux Bahagian 2" dan termasuk sesuatu seperti "mount 和 sync 的 C 版本函数。这些函数的二进制布局是 Linux ABI 的第一个重要组成部分。对于问题 “Linux 的稳定 ABI 包括哪些内容?”,许多用户和开发人员的回答是 “sysfs(/sys)和 procfs(/proc) yang boleh dipanggil daripada aplikasi perisian tengah. Malah, rasmi The Linux ABI dokumentasi memfokuskan terutamanya pada sistem fail maya ini

Bahagian sebelumnya memfokuskan pada cara Linux ABI digunakan dalam program, tetapi tidak merangkumi faktor manusia yang sama pentingnya dengan keperluan fungsian ABI (seperti GCC atau clang), pembangun mencipta perpustakaan ruang pengguna C (biasanya glibc), dan aplikasi binari yang dibentangkan dalam Format Boleh Laksana dan Pemautan (ELF) Usaha kolaboratif dalam komuniti

十分钟让你了解 Linux ABI

Mengapa kita mengambil berat tentang ABI?

Jaminan kestabilan Linux ABI daripada Torvalds sendiri membolehkan pengedaran Linux dan pengguna individu mengemas kini kernel secara bebas tanpa terjejas oleh sistem pengendalian.

Jika Linux tidak mempunyai ABI yang stabil, kebanyakan atau bahkan semua sistem pengendalian perlu dipasang semula setiap kali kernel perlu ditampal untuk menangani isu keselamatan. Jelas sekali, kestabilan antara muka binari adalah salah satu faktor penting dalam kebolehgunaan dan penggunaan meluas Linux.

十分钟让你了解 Linux ABIKeluaran terminal

Seperti yang ditunjukkan dalam gambar di atas, kernel (dalam linux-libc-dev ) dan Glibc (dalam apt Pengurus pakej akan mengenal pasti setiap fail yang disediakan oleh pakej. Bahagian Glibc ABI yang mungkin tidak stabil terletak dalam bits/ direktori. linux-libc-dev 中)和 Glibc(在 libc6-dev 中)都提供了定义文件权限的位掩码。显然,这两个定义集必须一致!apt 软件包管理器会识别软件包提供每个文件。Glibc ABI 的潜在不稳定部分位于 bits/ 目录中。

在大部分情况下,Linux ABI 的稳定性保证运作良好。按照 康韦定律Conway's Law,在开发过程中出现的烦人技术问题往往是由于不同软件开发社区之间的误解或分歧所致,而这些社区都为 Linux 做出了贡献。不同社区之间的接口可以通过 Linux 包管理器的元数据轻松地进行想象,如上图所示。

Y2038:一个 ABI 破坏的例子

通过考虑当前正在进行的、缓慢发生 的 “Y2038” ABI 破坏的例子,可以更好地理解 Linux ABI。在 2038 年 1 月,32 位时间计数器将回滚到全零,就像较旧车辆的里程表一样。2038 年 1 月听起来还很遥远,但可以肯定的是,如今销售的许多物联网设备仍将处于运行状态。像今年安装的 智能电表 和 智能停车系统 这样的普通产品可能采用的是 32 位处理器架构,而且也可能不支持软件更新。

Linux 内核已经在内部转向使用 64 位的 time_t 不透明数据类型来表示更晚的时间点。这意味着像 time() 这样的系统调用在 64 位系统上已经变更了它们的函数签名。这些努力的艰难程度可以在内核头文件中(例如 time_types.h)清楚地看到,在那里放着新的和 _old

Jaminan kestabilan ABI Linux berfungsi dengan baik dalam kebanyakan kes. Menurut Undang-undang Conway, masalah teknikal menjengkelkan yang berlaku semasa proses pembangunan selalunya disebabkan oleh Salah Faham atau perselisihan faham perisian yang berbeza antara komuniti yang telah menyumbang kepada Linux. Antara muka antara komuniti yang berbeza boleh dibayangkan dengan mudah melalui metadata pengurus pakej Linux, seperti yang ditunjukkan dalam rajah di atas.

十分钟让你了解 Linux ABIY2038: Contoh pecah ABI dengan mengambil kira contoh pecah ABI "Y2038" yang sedang berjalan dan perlahan untuk memahami Linux ABI dengan lebih baik. Pada Januari 2038, pembilang masa 32-bit akan kembali kepada semua sifar, sama seperti odometer pada kenderaan lama. Januari 2038 mungkin masih kedengaran jauh, tetapi ini adalah pertaruhan yang selamat bahawa banyak peranti IoT yang dijual hari ini masih akan beroperasi. Seperti smart meter

dan Sistem letak kereta pintar

Produk biasa sedemikian mungkin menggunakan seni bina pemproses 32-bit dan mungkin tidak menyokong kemas kini perisian. Inti Linux telah beralih kepada menggunakan 64-bit secara dalaman -indent: 0px display: inline-block;">time_t Jenis data legap untuk mewakili titik masa kemudian. Ini bermaksud sesuatu seperti time() telah menukar tandatangan fungsinya pada sistem 64-bit. Besarnya usaha ini boleh dilihat dengan jelas dalam fail pengepala kernel seperti time_types.h, di mana Letakkan baharu dan versi _old struktur data.

🎜🎜Odometer flipping🎜🎜🎜Projek Glibc juga 🎜menyokong masa 64-bit🎜, jadi anda sudah bersedia, bukan? Malangnya, berdasarkan perbincangan mengenai 🎜senarai mel Debian🎜 , ini tidak berlaku. Distro menghadapi pilihan yang sukar sama ada menyediakan dua versi semua pakej binari untuk sistem 32-bit atau menyediakan dua versi untuk media pemasangan. Dalam kes kedua, pengguna pada masa 32-bit perlu menyusun semula aplikasi mereka dan memasang semula. Seperti biasa, aplikasi proprietari adalah pening kepala. 🎜

Apakah sebenarnya yang disertakan dalam ABI stabil Linux?

Memahami ABI yang stabil agak rumit. Sesuatu yang perlu dipertimbangkan ialah walaupun kebanyakan sysfs ialah ABI yang stabil, antara muka nyahpepijat pastinya tidak stabil kerana ia mendedahkan dalaman kernel kepada ruang pengguna. Linus Torvalds pernah berkata, "Jangan pecahkan ruang pengguna", dan biasanya dia bermaksud melindungi pengguna biasa yang "hanya mahu ia berfungsi", dan bukannya pengaturcara sistem dan jurutera kernel, yang sepatutnya boleh membaca dokumentasi kernel dan kod sumber untuk memahami apa yang telah berubah antara versi. Imej di bawah menggambarkan perbezaan ini.

十分钟让你了解 Linux ABIJaminan Kestabilan

Tidak mungkin pengguna biasa akan berinteraksi dengan bahagian ABI Linux yang tidak stabil, tetapi pengaturcara sistem mungkin berbuat demikian secara tidak sengaja. Kecuali /sys/kernel/debug Kecuali, sysfs (/sys) dan procfs (/proc) adalah stabil. /sys/kernel/debug 以外,sysfs(/sys)和 procfs(/proc)的所有部分都是稳定的。

那么其他对用户空间可见的二进制接口如何呢,包括 /dev 中的设备文件、内核日志文件(可通过 dmesg

Bagaimana pula dengan antara muka binari lain yang boleh dilihat oleh ruang pengguna, termasuk Fail peranti dan fail log kernel dalam/dev (boleh diakses melalui Memasang sistem fail lama<p></p>Selain fakta bahawa sistem Linux digantung semasa but, ketidakupayaan untuk memasang sistem fail adalah perkara yang paling mengecewakan. Jika sistem fail menggunakan SSD pelanggan yang membayar, maka masalahnya benar-benar serius. Sistem fail Linux yang boleh dipasang di bawah versi kernel lama masih boleh dipasang apabila kernel dinaik taraf, bukan? Malah, "ia bergantung." <p><a target="_blank" href="https://www.php.cn/link/05298fdb6c0c3d665cea702d1f85acda">Pada tahun 2020, seorang pembangun Linux yang terkilan </a>mengadu</p> pada senarai mel kernel: <blockquote style="margin-top: 5px; margin-bottom: 5px; padding-left: 1em; margin-left: 0px; border-left: 3px solid rgb(238, 238, 238); opacity: 0.6;"> <p></p>Inti telah menerima ini sebagai format sistem fail boleh lekap yang sah tanpa sebarang pepijat atau isu apa-apa jenis Amaran, dan telah berfungsi dengan pasti seperti ini untuk tahun... Saya secara amnya menganggap bahawa pemasangan sistem fail akar sedia ada berada dalam skop kernel<->ruang pengguna atau kernel<-> sempadan sistem sedia ada, seperti yang ditakrifkan oleh Menaik taraf kernel harus serasi dengan ruang pengguna dan sistem sedia ada , ditakrifkan oleh apa yang diterima oleh kernel dan digunakan dengan jayanya oleh ruang pengguna sedia ada. </blockquote> <p><a target="_blank" href="https://www.php.cn/link/4d22136ec8f25b566fdd61bc0d5045b4">Tetapi terdapat masalah: sistem fail yang tidak boleh dipasang ini dibuat menggunakan alat proprietari yang bergantung pada bendera yang ditakrifkan oleh, tetapi tidak digunakan oleh, kernel. Bendera ini tidak muncul dalam pengepala API atau procfs/sysfs Linux, tetapi merupakan </a>perincian pelaksanaan<a target="_blank" href="https://www.php.cn/link/cc26f87f3f9f7c0fbf2d36ad880a9a4e">. Oleh itu, mentafsir bendera ini dalam kod ruang pengguna bermakna bergantung pada "</a>Tingkah laku tidak ditentukan<a target="_blank" href="https://www.php.cn/link/1b2bae9eed46f0f6d38fdf582952f3b1">", frasa yang membuatkan hampir setiap pembangun perisian menggigil. Apabila komuniti kernel menambah baik ujian dalamannya dan mula menjalankan semakan konsisten baharu, panggilan sistem "</a>man 2 mount</p>" tiba-tiba mula menolak sistem fail dengan format proprietari. Memandangkan pencipta format itu jelas merupakan pembangun perisian, dia gagal mendapat simpati daripada penyelenggara sistem fail kernel. <p style="text-align:center;"><img src="https://img.php.cn/upload/article/000/887/227/169105158644205.jpg" alt="十分钟让你了解 Linux ABI"><span></span>Papan tanda pembinaan mengatakan kru sedang bekerja di atas pokok</p>🎜<h3>Log dmesg kernel berulir</h3> <p><code style="background-color: rgb(231, 243, 237); padding: 1px 3px; border-radius: 4px; overflow-wrap: break-word; text-indent: 0px; display: inline-block;">Adakah format fail dalam direktori /dev dijamin stabil atau tidak stabil? arahan dmesg /dev 目录中的文件格式是否保证稳定或不稳定?dmesg 命令 会从文件 /dev/kmsg 中读取内容。2018 年,一位开发人员 为 dmesg 输出实现了线程化,使内核能够“在打印一系列 printk() 消息到控制台时,不会被中断和/或被其他线程的并发 printk() 干扰”。听起来很棒!通过在 /dev/kmsg 输出的每一行添加线程 ID,实现了线程化。密切关注的读者将意识到这个改动改变了 /dev/kmsg 的 ABI,这意味着解析该文件的应用程序也需要进行相应的修改。由于许多发行版没有编译启用新功能的内核,大多数使用 /bin/dmesg 的用户可能没有注意到这件事,但这个改动破坏了 GDB 调试器 读取内核日志的能力。

确实,敏锐的读者会认为 GDB 的用户运气不佳,因为调试器是开发人员工具。实际上并非如此,因为需要更新以支持新的 /dev/kmsg akan dibaca daripada fail untuk keluaran dmesg, membenarkan kernel "mencetak siri <code style="background-color: rgb(231, 243, 237); overflow-wrap: break-word; text-indent: 0px display: inline-block;"> printk() Apabila mesej dihantar ke konsol, ia tidak akan diganggu dan/atau disetujui oleh utas lain printk() gangguan". Bunyi hebat! Oleh /dev/kmsg Menambah ID benang pada setiap baris output untuk mencapai penjalinan. Pembaca yang memberi perhatian dengan teliti akan menyedari bahawa perubahan ini berubah /dev/kmsg's ABI, yang bermaksud bahawa aplikasi yang menghuraikan fail juga perlu diubah suai dengan sewajarnya. Memandangkan banyak pengedaran tidak menyusun kernel dengan ciri baharu didayakan, kebanyakan menggunakan /bin/dmesg Pengguna mungkin tidak menyedari ini, tetapi perubahan ini memecahkan Penyahpepijat GDB Keupayaan untuk membaca log kernel.

Sesungguhnya, pembaca yang bijak akan menganggap bahawa pengguna GDB tidak bernasib baik kerana penyahpepijat ialah alat pembangun. Ini sebenarnya tidak berlaku kerana ia perlu dikemas kini untuk menyokong /dev/kmsg Kod dalam format terletak di bahagian "in-tree" pada repositori kod sumber Git kernel sendiri. Untuk projek biasa, adalah satu kesilapan yang jelas jika program dalam satu pangkalan kod tidak berfungsi bersama, jadi

patch untuk membolehkan GDB berfungsi dengan threaded /dev/kmsg

telah digabungkan. Bagaimana dengan program BPF? BPF ialah alat berkuasa yang boleh dipantau dalam kernel yang sedang berjalan dan juga dikonfigurasikan dalam masa nyata. BPF pada asalnya direka untuk menyokong konfigurasi rangkaian masa nyata dengan membenarkan pentadbir sistem mengubah suai penapis paket dengan segera dari baris arahan. Alexei Starovoitov dan lain-lain telah memanjangkan BPF untuk dapat mengesan fungsi kernel sewenang-wenangnya. Pengesanan jelas merupakan domain pembangun, bukan pengguna biasa, jadi ia jelas tidak tertakluk kepada sebarang jaminan ABI (walaupun panggilan sistem

bpf()

mempunyai janji kestabilan yang sama seperti panggilan sistem lain). Sebaliknya, mencipta program BPF dengan fungsi baharu membuka kemungkinan "menggantikan modul kernel sebagai cara standard de facto untuk memanjangkan kernel". Modul kernel menjadikan peranti, sistem fail, penyulitan, rangkaian, dsb. berfungsi dengan baik, begitu juga kemudahan yang boleh dipercayai oleh pengguna biasa yang "hanya mahu ia berfungsi". Masalahnya ialah, tidak seperti kebanyakan modul kernel sumber terbuka, program BPF secara tradisinya tiada dalam kod sumber kernel.

Pada musim bunga 2022, satu cadangan menjadi tumpuan, mencadangkan untuk menyediakan sokongan untuk pelbagai peranti antara muka manusia (seperti tetikus dan papan kekunci) menggunakan program BPF mini dan bukannya tampung pemacu peranti.

🎜Perbincangan rancak berlaku, tetapi isu itu nampaknya telah diselesaikan dalam 🎜komen Torvalds 🎜 di Sidang Kemuncak Sumber Terbuka: 🎜

Beliau menegaskan bahawa jika anda memecahkan "alat ruang pengguna sebenar yang digunakan oleh pengguna biasa (bukan pembangun kernel)" maka anda perlu membetulkannya, sama ada eBPF digunakan atau tidak.

Konsensus nampaknya muncul bahawa pembangun yang mahu program BPF mereka masih berfungsi selepas kemas kini kernel perlu meletakkannya ke lokasi yang belum ditentukan dalam repositori kod sumber kernel. Nantikan untuk melihat dasar yang diterima pakai oleh komuniti kernel berkenaan kestabilan BPF dan ABI.

Kesimpulan

Jaminan kestabilan ABI kernel digunakan untuk procfs, sysfs dan antara muka panggilan sistem, tetapi terdapat pengecualian penting. Apabila pertukaran kernel memecahkan kod "dalam-pokok" atau aplikasi ruang pengguna, tampung yang menyinggung selalunya digulung semula dengan cepat. Untuk kod proprietari yang bergantung pada butiran pelaksanaan kernel, walaupun butiran ini boleh diakses dari ruang pengguna, ia tidak dilindungi dan menerima simpati terhad apabila masalah timbul. Apabila isu seperti Y2038 tidak dapat mengelakkan ABI pecah, peralihan dibuat dengan cara yang paling disengajakan dan sistematik yang mungkin. Dan ciri baharu seperti program BPF menimbulkan persoalan yang belum terjawab tentang sempadan kestabilan ABI.

PENGHARGAAN

Terima kasih kepada Akkana Peck, Sarah R. Newman dan Luke S. Crawford atas komen berguna mereka pada versi bahan terdahulu.

Atas ialah kandungan terperinci Ketahui tentang Linux ABI dalam sepuluh minit. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Artikel ini dikembalikan pada:51cto.com. Jika ada pelanggaran, sila hubungi admin@php.cn Padam
Artikel sebelumnya:Nginx - konfigurasi minimumArtikel seterusnya:Nginx - konfigurasi minimum