Menulis klon Unix dalam waktu sekitar satu bulan

 (drewdevault.com)
3 poin oleh GN⁺ 2024-05-25 | 1 komentar | Bagikan ke WhatsApp
  • Bunnix, yang dimulai sebagai proyek untuk bersantai, menguji seberapa jauh sistem operasi keluarga Unix untuk x86_64 bisa dibuat dalam waktu sekitar satu bulan, dan secara hitungan hari kerja nyata memakan waktu 27 hari
  • Kernel-nya terutama ditulis dengan Hare, sambil menggunakan komponen C seperti lwext4 untuk dukungan ext4 dan libvterm untuk terminal video kernel
  • Mendukung legacy boot maupun EFI dan sudah diuji pada beberapa laptop sungguhan, tetapi karena tidak mendukung USB, diperlukan keyboard PS/2 atau emulasi PS/2 dari BIOS
  • Ruang pengguna berpusat pada perangkat lunak pihak ketiga seperti dash, Doom, gzip, less, mandoc, sbase, tcc, dan Vim 5.7, sementara libc merupakan bentuk musl libc yang dimodifikasi agar sesuai untuk Bunnix
  • Bunnix berfungsi, tetapi masih banyak bug dan tetap merupakan sistem pengguna tunggal; proyek ini lebih merupakan eksperimen yang mengarah ke pengerjaan ulang Helios dan perbaikan desain kernel daripada pemeliharaan jangka panjang

Cakupan dan menjalankan Bunnix

  • Bunnix adalah proyek sistem operasi keluarga Unix untuk x86_64 yang dimulai pada 21 April 2024
  • Jika mengecualikan hari-hari tanpa pengerjaan, total waktu yang dihabiskan adalah 27 hari
  • Tersedia Bunnix 0.0.0 iso yang bisa dijalankan langsung
  • Di qemu, ISO dapat di-boot dengan perintah berikut
qemu-system-x86_64 -cdrom bunnix.iso -display sdl -serial stdio
  • ISO dapat ditulis ke USB stick untuk di-boot di perangkat keras nyata
    • Kemungkinan dapat berjalan di sebagian besar mesin AMD64
    • Diuji pada ThinkPad X220 dan Starlabs Starbook Mk IV
    • Mendukung legacy boot dan EFI
  • Batasan terbesar saat menjalankan sistem ini adalah tidak adanya dukungan USB
    • Diperlukan keyboard PS/2 atau emulasi PS/2 dari BIOS
    • Sebagian besar keyboard laptop terhubung dengan metode PS/2
    • Apakah emulasi PS/2 untuk keyboard USB berfungsi atau tidak tergantung lingkungan
  • Port Doom memiliki keterbatasan pada key binding dan perilaku keluar
    • Bergerak dengan WASD
    • Menembak dengan Shift kanan
    • Membuka pintu dengan Space
    • Keluar dari game tidak berfungsi, jadi perlu reboot setelah bermain

Struktur kernel dan fitur yang didukung

  • Kernel Bunnix sebagian besar ditulis dengan Hare dan menggunakan beberapa komponen C
    • Menggunakan lwext4 untuk dukungan filesystem ext4
    • Menggunakan libvterm untuk terminal video kernel
  • Driver yang didukung berfokus pada perangkat keras dasar dan cakupan yang diperlukan untuk boot dari media penyimpanan
    • PCI legacy
    • perangkat blok AHCI
    • tabel partisi GPT dan MBR
    • keyboard PS/2
    • port serial platform
    • clock CMOS
    • framebuffer yang disiapkan bootloader
    • filesystem ext4 dan memfs
  • Fitur kernel dasar yang dibutuhkan sistem keluarga Unix juga disertakan

    • Filesystem virtual dan perangkat

      • Menyediakan /dev dengan perangkat blok, perangkat semu null, zero, full, /dev/kbd, /dev/fb0, TTY serial dan video, serta terminal kontrol /dev/tty
      • Termasuk emulator terminal yang relatif matang dan dukungan termios yang cukup berfungsi

    • System call dan model pengguna

      • Mendukung sekitar 40 system call, termasuk clock_gettime, poll, openat, fork, exec, pipe, dup, dup2, dan ioctl
      • Saat ini Bunnix adalah sistem pengguna tunggal
      • Tidak menegakkan mode file dan kepemilikan ala Unix
      • Dengan beberapa hari kerja tambahan, sistem ini berada pada kondisi yang bisa dijadikan sistem multi-pengguna

Bootloader dan ruang pengguna

  • Bunnix menyertakan dua bootloader
    • Bootloader untuk legacy boot kompatibel dengan multiboot dan ditulis dengan Hare
    • Bootloader untuk EFI ditulis dalam C
  • Kedua bootloader memuat kernel sebagai file ELF dan initramfs bila diperlukan
    • Bootloader EFI menyertakan zlib untuk dekompresi initramfs
    • Bootloader kompatibel multiboot menangani dekompresi sebagai gantinya
  • Ruang pengguna sebagian besar terdiri dari sumber pihak ketiga
    • Colossal Cave Adventure advent
    • dash /bin/sh
    • Doom
    • gzip
    • less
    • lok /bin/awk
    • lolcat
    • mandoc
    • sbase core utils
    • tcc C compiler
    • Vim 5.7
  • libc diturunkan dari musl libc dan menerima berbagai modifikasi agar sesuai dengan kebutuhan Bunnix
  • Library curses berbasis netbsd-curses
  • Sistem ini berfungsi, tetapi banyak bug dan beberapa bagian implementasinya dibuat terburu-buru, jadi perlu siap menghadapi crash

Faktor yang memungkinkan implementasi cepat dan tantangannya

  • Sebagian kode Bunnix berasal dari proyek sebelumnya, Helios
    • Termasuk sebagian kode kernel terkait penyiapan CPU umum seperti GDT dan IDT
    • Beberapa driver seperti AHCI juga disesuaikan dengan sistem Bunnix
    • Tanpa pengalaman dari Helios, kemungkinan akan sulit membuat Bunnix secepat ini
  • Dukungan ext4 dan integrasi terminal virtual sangat sulit secara khusus
    • Mengambil dependensi eksternal berupa lwext4 dan libvterm
    • Lapisan filesystem ditulis ulang beberapa kali dan saat ini masih menyisakan bug
    • Untuk menerapkan desain filesystem Unix dengan benar, termasuk openat dan penanganan inode, perlu menelaah lebih dalam bagian internal lwext4
  • Di dalam proyek Hare, ada juga pengalaman menghubungkan source Hare, assembly, dan C secara bersama-sama
    • Secara umum berjalan baik, tetapi ada ketidaknyamanan saat membuat mekanisme integrasi ABI
    • Muncul kebutuhan akan konversi otomatis header C menjadi modul forward declaration Hare
    • Beberapa pekerjaan terkait sudah ada di hare-c, tetapi masih perlu lebih banyak lagi
  • Menargetkan port Vim membuat tingkat kesulitan implementasi terminal meningkat
    • libvterm adalah library state machine terminal yang bagus, tetapi dokumentasinya kurang
    • Banyak penyesuaian kecil diperlukan agar integrasinya akurat
    • Waktu juga dihabiskan untuk optimasi performa agar semuanya berjalan mulus
  • Scheduler adalah area yang banyak ditulis ulang dengan meninggalkan sebagian besar kode berbasis Helios
    • Helios dan Bunnix sama-sama merupakan sistem CPU tunggal
    • Tidak seperti Helios, Bunnix mengizinkan context switch di dalam kernel
    • Peralihan tugas preemptive juga masuk dan keluar melalui kernel
    • Struktur ini memerlukan beberapa stack kernel dan cara peralihan tugas yang berbeda
    • Dengan scheduler yang cukup kokoh, operasi blocking seperti pembacaan disk atau pipe(2) bisa diimplementasikan secara sederhana dengan wait queue
  • Implementasi signal diperlukan demi kompatibilitas Unix
    • Helios tidak menargetkan Unix sehingga bisa berjalan tanpa signal
    • Di Bunnix, implementasi terutama disesuaikan agar SIGCHLD bekerja benar untuk port dash
    • Implementasi signal akhirnya masih berada pada tingkat yang sangat dasar

Pelajaran desain yang berlanjut ke Helios

  • Bunnix adalah kernel monolitik sedangkan Helios adalah desain microkernel non-Unix
  • Pada filesystem, pentingnya caching menjadi makin jelas
    • Helios membagi implementasi filesystem ke beberapa driver dan proses terpisah
    • Caching penting bahkan hanya untuk melacak objek yang masih hidup
    • Saat pengerjaan ulang Helios, akan ada banyak pekerjaan untuk merapikan atau menulis ulang kode filesystem
  • Pendekatan driver secara alami lebih sederhana dalam kernel monolitik
    • Namun, tidak sepenuhnya puas karena terlalu banyak hal ditempatkan di ring 0
    • Ada ruang untuk mencerminkan beberapa elemen alur kontrol desain monolitik ke scheduler Helios
  • Dalam manajemen memori, bitmap allocator bekerja lebih baik dari perkiraan
    • Di Helios, bitmap allocator sempat ingin dihindari dan manajemen memori menjadi titik ketidaknyamanan besar
    • Bunnix menggunakan bitmap allocator sederhana untuk seluruh halaman umum sistem
    • Overhead-nya tidak sebesar yang dikhawatirkan dan bekerja sangat baik
  • Penulis menilai membuat Bunnix dalam 30 hari tidak akan mungkin dengan desain microkernel
    • Kernel monolitik jauh lebih sederhana untuk diimplementasikan
    • Kelebihan desain microkernel juga tetap menarik, dan jawaban yang lebih baik mungkin adalah kernel hibrida

Status proyek dan kandidat perbaikan yang tersisa

  • Bunnix lebih mendekati proyek seni yang hampir selesai daripada sesuatu yang akan terus diberi banyak waktu ke depan
    • Sesekali masih bisa dikerjakan selama beberapa hari
    • Perbaikan dari komunitas dapat dikirim sebagai patch ke public inbox
  • Pengembangan OS selanjutnya akan kembali ke Helios, dengan melakukan redesain besar berdasarkan pelajaran dari Bunnix
  • Kandidat prioritas perbaikan adalah sebagai berikut
    • cache direktori untuk filesystem dan peningkatan caching secara umum
    • perbaikan bug ext4
    • procfs dan top
    • file mmap
    • signal tambahan seperti SIGSEGV
    • dukungan multi-pengguna
    • perangkat blok NVMe
    • perangkat blok IDE
    • dukungan ATAPI dan ISO 9660
    • dukungan Intel HD audio
    • network stack
    • toolchain Hare untuk sistem dasar
    • self-hosting

Bacaan terkait

1 komentar

 
GN⁺ 2024-05-25
Komentar Hacker News

  • Benar-benar keren. Ini mengingatkan pada cerita bahwa Unix asli juga dibuat dalam beberapa minggu ketika keluarga Ritchie pergi berlibur ke California untuk mengunjungi mertua
    Sumbernya adalah UNIX: A History and a Memoir karya Brian W. Kernighan

    • Penting untuk dicatat bahwa sebelum memakai Unix pun mereka sudah lama mengerjakan Multics. Kalau ingatan saya benar, Unix lebih mirip versi yang “disederhanakan” dari itu, bukan sesuatu yang tiba-tiba muncul dari nol
    • Sepertinya yang dimaksud adalah Ken Thompson. Saya malas mencari wawancaranya di YouTube, tetapi saya ingat ia beberapa kali bercerita bahwa driver disk, beberapa program, dan komponen lain sudah ada, lalu saat istrinya bepergian ia merasa punya waktu untuk mengisi bagian yang kosong dan menjadikannya sistem operasi lengkap
    • Unix sendiri sebaiknya dianggap memakan waktu lama. Jika V7 dianggap sebagai “Unix yang benar-benar lengkap”, itu butuh beberapa tahun, dan versi pertamanya, misalnya, hanya berupa sistem berkas
    • Setahu saya ceritanya tentang 3 program yang masih hilang, dan salah satunya adalah editor teks
      Ingatan saya sekarang agak kabur, jadi perlu saya cek lagi
    • Sepertinya Anda tertukar antara Dennis Ritchie dan Ken Thompson

  • Saya ingin melihat materi yang lebih rinci tentang bagian yang mengatakan, “Akhirnya saya belajar bagaimana sinyal bekerja dari atas sampai bawah, dan itu benar-benar jelek. Saya selalu merasa itu salah satu bagian terlemah dalam desain Unix, dan proyek ini tidak mengubah pendapat itu.” Kalau ada pengguna HN atau penulis yang tahu, saya penasaran

    • Jika belum melihatnya, saya akan mulai dari Advanced Programming in the Unix Environment karya Stevens
      https://www.amazon.com/Advanced-Programming-UNIX-Environment...
      Buku itu membahas tanggung jawab menangani API Unix di ruang pengguna, termasuk sinyal dan proses
      Kalau ingin mengimplementasikan sinyal di dalam kernel, saya tidak begitu yakin apa yang harus direkomendasikan, tetapi yang terlintas mungkin https://pdos.csail.mit.edu/6.828/2012/xv6.html
      Membaca buku yang menjelaskan dengan jelas dan sistematis cara kerja Unix, lengkap dengan contoh yang mandiri, benar-benar menyegarkan. Jika tidak tahu C, itu bisa menjadi hambatan, tetapi hal yang sama juga berlaku saat membaca artikel blog
      Saya tidak menganggap ada informasi setara di suatu tempat di web. Di blog saya sendiri pun ada banyak pengetahuan serba-serbi Unix yang masih dibaca orang, tetapi tidak pada level yang sama
      Menurut saya, memahami sinyal Unix adalah salah satu topik yang sangat tidak efisien jika didekati lewat artikel blog, Google, atau LLM. Bahkan bekas pun sulit disebut “murah”, tetapi buku itu harganya tetap tinggi karena informasinya bernilai, dan bagi programmer profesional relatif murah
    • Sinyal berada di titik pertemuan antara I/O/panggilan sistem asinkron dan komunikasi antarproses. Asinkron dan IPC juga memang titik lemah desain Unix dan bukan elemen yang ada sejak awal
      Sinyal adalah upaya canggung untuk menambalkan IPC asinkron ke dalam desain, sehingga rentan terhadap race condition. Juga tidak jelas apa yang terjadi jika sinyal lain diterima saat sedang menangani sinyal, atau bagaimana menangani sinyal ketika proses sedang berada di panggilan sistem. Harus diputuskan apakah akan menundanya, memasukkannya ke antrean, atau mengeluarkan proses dari panggilan sistem
      Jika semua panggilan sistem bersifat asinkron, seperti prinsip desain yang diikuti banyak sistem operasi modern, aspek itu terselesaikan. Jika IPC memiliki sistem seperti kanal yang andal, bukan hanya sinyal, melainkan komunikasi atau pemanggilan prosedur antarproses asinkron yang lebih canggih juga bisa diimplementasikan
    • Saya rasa ada orang yang tidak suka sinyal Unix karena ia memikul terlalu banyak konsep yang berbeda
      SIGSTOP/SIGCONT/SIGKILL sebenarnya lebih merupakan kontrol proses seperti menjeda, melanjutkan, dan menghentikan, bukan benar-benar mengirim sinyal ke proses
      Pesan asinkron sederhana seperti SIGHUP, SIGUSR1, SIGUSR2, SIGTTIN, SIGTTOU disalahgunakan untuk hal-hal seperti membaca ulang konfigurasi, dan ditambahi workaround bergaya hack seperti nohup untuk daemonisasi. gunicorn bahkan memakai dua yang terakhir untuk penskalaan naik-turun dinamis. Dalam kategori ini juga ada yang anehnya sangat spesifik seperti SIGWINCH
      Lalu ada juga yang menunjukkan instruksi tidak valid, pelanggaran segmentasi, dan pengecualian floating-point seperti SIGILL, SIGSEGV, SIGFPE. Ada pula yang sejak awal agak meragukan apakah sebaiknya dibuat asinkron, seperti SIGSYS
      Pendekatan lain juga punya trade-off. Windows memiliki event, SEH, rutin penanganan CTRL+C/CTRL+BREAK/terminasi, IOCP, callback, dan sebagainya. notes di Plan 9 berupa string, jadi bagus karena bisa mengirim data arbitrer ke proses lain, tetapi memakai mekanisme yang sama untuk kontrol proses punya kelemahan yang sama seperti *nix, dan menurut saya itu hanya string alih-alih angka
    • “signalfd is useless” adalah tulisan yang bagus: https://ldpreload.com/blog/signalfd-is-useless
      Tulisan itu membahas masalah sinyal Unix dan menjelaskan mengapa signalfd, yang dibuat Linux untuk mencoba menyelesaikannya, juga tidak bekerja dengan baik
    • Saat menulis aplikasi portabel, perbedaan penanganan sinyal antara BSD dan SYSV menjadi masalah
      https://pubs.opengroup.org/onlinepubs/009604499/functions/bs...
      Penting juga bahwa kode di dalam handler sinyal harus reentrant. “Fungsi yang tidak reentrant umumnya tidak aman untuk dipanggil dari handler sinyal”
      https://man7.org/linux/man-pages/man7/signal-safety.7.html

  • Saya sempat tertarik pada Hare, tetapi setelah melihat entri FAQ ini saya merasa itu kebijakan yang sangat merugikan diri sendiri: https://harelang.org/documentation/faq.html#will-hare-suppor...
    Pada dasarnya saya mendukung developer memakai lisensi yang mereka inginkan, menargetkan sistem operasi yang mereka inginkan, dan menulis kode yang mereka inginkan
    Namun itu tidak otomatis membuat kebijakan khusus ini menjadi ide yang bagus. Bahkan FSF, yang dianggap sebagai kelompok paling ekstrem atau paling berprinsip dalam filosofi free software, mendukung Windows dan POSIX. Orang boleh mengeluh dan menyebutnya Woe32, tetapi Stallman telah cukup meyakinkan mengatakan bahwa membuat proyek free software dapat berjalan juga di sistem proprietary lebih membantu perjuangan menuju dunia tanpa proprietary software
    Kode library dilisensikan dengan MPL, jadi sekadar memakai Hare tidak mengikat Anda pada lisensi tertentu. Namun saya ragu berapa lama umur sebuah bahasa yang bersikap kepada lebih dari 95% desktop dengan “tidak didukung, jangan bertanya di forum, jangan datang ke sini”
    Ironisnya, jika mencari “harelang repo” di Google, hasil pertama adalah port macOS tidak resmi, sementara repositori SourceHut yang sebenarnya tidak muncul di halaman pertama
    Bahasa pemrograman membesar seperti bola salju atau menghilang. Saya menulis ini dari Mac, tetapi kalau mau saya juga bisa langsung memakai mesin Linux sekarang. Lalu mengapa harus mempelajari bahasa yang memaksakan uji kemurnian kepada developer, sesuatu yang bahkan FSF pun tidak lakukan? Sebagian besar open source dan free software ditulis di Mac, dan lebih banyak dari yang dikira juga ditulis di Windows
    Menurut saya, yang membedakan Hare dari Odin atau Zig justru sikap kemurnian dan eksklusi seperti ini. Saya berharap mereka bisa menikmati hacking dan meraih sukses, tetapi untuk yang kedua saya pesimistis

    • Di satu sisi, saya bisa menghormati para penulisnya yang berpegang pada apa yang ingin mereka capai dan tidak menerima semua permintaan
      Di sisi lain, itu bukan satu-satunya bagian FAQ yang membuat alis terangkat
      “Tidak ada package manager, dan sebagai nilai bersama kami kurang mendorong reuse kode”
      “qbe menghasilkan kode yang lebih lambat daripada LLVM, dengan performa runtime sekitar 25–75% dibanding kode hasil LLVM yang sepadan”
      “Bisakah memakai multithreading di Hare? Mungkin tidak”
      “Jadi apakah saya harus mengimplementasikan hash table sendiri? Ya. Hash table adalah struktur data umum yang harus diimplementasikan banyak program Hare dari awal”
      Untuk saat ini, ini jelas bukan bahasa yang dirancang dengan tujuan adopsi massal. Itu tidak apa-apa, dan setidaknya mereka jujur tentang hal itu
    • Saya tidak setuju dengan istilah “memaksakan”. Jika seseorang melakukan sesuatu secara gratis, selama tidak berniat jahat, mereka tidak berkewajiban melakukannya dengan cara tertentu
      Bebas saja menyampaikan pendapat, tetapi ketika developer sudah menetapkan pedomannya, menurut saya kritik seperti ini tidak konstruktif
    • Sepertinya Anda dan pihak Hare punya definisi sukses yang berbeda. Pernyataan “bahasa pemrograman membesar seperti bola salju atau menghilang” juga terasa cukup meremehkan banyak bahasa yang terus berkembang selama puluhan tahun meski tidak punya popularitas setingkat rockstar
      Tidak semua band harus masuk tangga lagu Billboard agar layak didengar
    • Artinya mereka secara resmi tidak akan mendukung Windows atau macOS. Kalau mau, bukankah proyek lain bisa mencoba melakukan porting? Menyatakan secara jujur tingkat dukungan yang diniatkan menurut saya baik
      Mendukung sistem operasi yang tidak dipakai para developer adalah tuntutan besar
    • Pernyataan “bahasa pemrograman membesar seperti bola salju atau menghilang” itu tidak benar dan naif
      Ada cukup banyak bahasa yang, meski secara umum tidak terlalu populer, berkembang di ceruk yang kuat dan memainkan peran penting

  • Mengesankan, sangat keren, dan menginspirasi. Contoh seperti “membuat sesuatu yang mengesankan dalam X hari” membutuhkan pengalaman dan bakat yang dibangun selama bertahun-tahun

    • Dibandingkan dengan zaman sekarang, saya butuh hampir seminggu hanya untuk mengubah satu teks tombol yang berisi string internasionalisasi
      Saya harus memasukkan string bahasa Inggris ke katalog, memperbarui berbagai pengujian, menjalankan pengujian di sistem lokal, mengunggah perubahan ke staging cluster, memperbaiki kegagalan pengujian yang tidak terduga, menaikkannya ke produksi, meminta penanggung jawab terjemahan menerjemahkannya ke beberapa bahasa, dan memperbarui dokumentasi juga
    • Ia juga pembuat KnightOS, yang ditulis lebih dari 12 tahun lalu hanya dengan assembly Z80
      https://www.ticalc.org/archives/files/fileinfo/463/46387.htm...
    • Drew memang pintar dan jadwalnya juga singkat, tetapi menurut saya keliru kalau melihatnya sekadar dengan memujanya. Membuat klon UNIX sebagian besar adalah proyek sarjana yang umum di universitas
      Yang diperlukan untuk mengembangkannya menjadi sesuatu yang matang lebih berupa ketekunan daripada kejeniusan luar biasa
    • Selain itu, ada implementasi kernel sebelumnya, Helios, yang menyediakan banyak bagian kode tingkat paling rendah. Bukan bermaksud meremehkan pencapaiannya, tetapi DD cukup terbuka mengatakan bahwa sebagian besar kecepatan proyek ini bergantung pada fakta bahwa ia sudah lebih dulu membuat Helios dan memakai ulang kodenya
    • Karena sudah ada Helios, ini pada dasarnya tinggal mengintegrasikan beberapa bagian yang belum ada

  • Sangat menyenangkan melihat pembaruan yang hampir setiap hari muncul di Mastodon. Kita bisa melihat orang yang berpengalaman menyusun perangkat lunak kompleks sedikit demi sedikit

  • Kodenya ada di sini: https://git.sr.ht/~sircmpwn/bunnix/tree/master
    Berlisensi GPLv3

  • User space sebagian besar dirakit dari sumber pihak ketiga
    Awalnya saya kaget ketika mengklik ISO dan muncul unduhan 60MB, tetapi kemudian saya paham alasannya
    Sebagai perbandingan, Linux 0.01 adalah unduhan 71KB, tetapi hanya berisi source kernel

  • Hare terlihat seperti bahasa yang menarik
    Namun, di era multicore ini, batasan berikut tampaknya akan membatasi adopsinya
    Menurut FAQ https://harelang.org/documentation/faq.html, untuk pertanyaan apakah multithreading bisa digunakan di Hare, jawabannya adalah “mungkin tidak”
    Untuk multiplexing operasi input/output, mereka menyarankan event loop; ketika perlu memakai resource CPU secara paralel, mereka menyarankan multiprocess dengan shared memory
    Secara ketat, program Hare bisa membuat thread. Bisa link ke libc lalu memakai pthreads, atau langsung menggunakan system call clone(2). Sistem operasi yang diimplementasikan dengan Hare seperti Helios biasanya mengimplementasikan multithreading
    Namun standard library upstream tidak memberikan jaminan reentrancy, jadi tanggung jawab sepenuhnya ada pada Anda sendiri agar tidak menembak kaki sendiri

    • “Jika perlu memakai resource CPU secara paralel, gunakan multiprocess dengan shared memory” sebenarnya cukup kuat
      Secara pribadi, saya lebih menyukai cara ini untuk sebagian besar penggunaan, karena kemungkinan data race dibatasi hanya pada area shared memory. Dari sudut pandang data race, rasanya seperti “unsafe block” pada memori
    • Jika standard library upstream tidak menjamin reentrancy, berarti bukan hanya multithreading, tetapi penggunaan di dalam interrupt juga dikecualikan. Untuk sebuah “bahasa pemrograman sistem”, menurut saya ini batasan yang cukup besar
    • Saya berharap ada closure

  • Ini berasal dari “Linux System Call Table – Chromiumos” https://www.chromium.org/chromium-os/developer-library/refer... https://news.ycombinator.com/item?id=33395777
    google/syzkalleR
    System call Fuschia / Zircon: https://fuchsia.dev/fuchsia-src/reference/syscalls