Fitur-fitur baru bahasa Rust untuk pengembangan kernel Linux

 (lwn.net)
13 poin oleh GN⁺ 2025-10-17 | 2 komentar | Bagikan ke WhatsApp
  • Proyek Rust for Linux mendorong fitur bahasa inti yang dibutuhkan untuk pengembangan kernel, sekaligus berkontribusi pada perkembangan bahasa Rust itu sendiri
  • Tiga hal yang menjadi inti adalah field projection, in-place initialization, dan arbitrary self types
  • Fitur-fitur ini memungkinkan struktur khas kernel seperti smart pointer, memori yang dipin (Pin), dan RCU diekspresikan lebih alami di Rust
  • Tim Rust menekankan stabilitas desain sehingga laju pengembangannya lambat, tetapi tujuan yang jelas berupa kernel Linux membuat fokus pengembangan menjadi lebih tinggi
  • Perubahan ini juga diperkirakan berdampak pada ekosistem Rust di luar kernel, dengan manfaat besar untuk penanganan smart pointer dan penyederhanaan kode

Peningkatan bahasa Rust dan peran kernel Linux

  • Alasan pengembangan fitur baru di bahasa Rust berjalan lambat adalah kehati-hatian agar desain yang buruk tidak terpatri di dalam bahasa serta masalah "alignment in attention"
    • Proyek Rust dijalankan oleh para sukarelawan, jadi jika tidak ada orang yang fokus pada fitur tertentu, pengembangannya akan tertunda
  • Karena proyek Rust for Linux adalah topik yang membuat banyak orang antusias, proyek ini membantu memusatkan upaya pada beberapa fitur inti yang dibutuhkan kernel
  • Co-lead tim bahasa Rust, Tyler Mandry, mempresentasikan fitur bahasa Rust yang akan datang di Kangrejos 2025 dan menyebut bahwa proyek kernel Linux berperan sebagai katalis bagi perkembangan Rust
    • Fitur utama: field projection, in-place initialization, arbitrary self types
    • Pengembangan kernel menyajikan use case nyata dan kebutuhan teknis secara jelas, sehingga membantu mematangkan arah desain bahasa Rust
    • Prioritas tertinggi saat ini adalah standarisasi fitur unstable yang sudah digunakan dalam binding kernel

Field Projection

  • Ini adalah fitur untuk mengekstrak pointer ke field tertentu dari pointer struct, sebuah upaya untuk menggeneralisasi ekspresi C &(r->field) ke dalam Rust
  • Sebelumnya hal ini hanya bisa dilakukan pada referensi (&) dan pointer (*mut), tetapi ada keterbatasan pada smart pointer buatan pengguna
  • Rust for Linux mendorong perluasan ini agar akses field dengan sintaks yang sama bisa dilakukan pada semua tipe pointer
  • Khusus saat menangani tipe Pin (struct yang tidak bisa dipindahkan), saat melakukan proyeksi field fitur ini dirancang agar otomatis berubah menjadi Pin<&mut Field> atau &mut Field
  • Jika fitur ini diimplementasikan, pola RCU (Read-Copy-Update) dapat didukung dengan aman di Rust, sehingga akses data berperforma tinggi bisa dilakukan tanpa lock
  • Saat ini sedang dibahas di tracking issue di GitHub, dengan target stabil sebelum Debian 14 (2027)

Arbitrary Self Types

  • Fitur yang memungkinkan definisi method yang menerima smart pointer
  • Sebelumnya hanya bentuk seperti fn method(&self) yang didukung, tetapi kini bentuk seperti fn method(self: Pin<&mut MyStruct>) juga dimungkinkan
  • Ini adalah fitur penting di kernel karena digunakan berbagai pembungkus pointer seperti Arc, Pin, dan Mutex
  • Dalam proses implementasinya sempat ada masalah benturan dengan trait Deref, tetapi sedang diselesaikan lewat pengenalan trait Receiver yang baru
  • Receiver berperan untuk menyatakan bahwa suatu pointer dapat digunakan sebagai arbitrary self type
  • Dalam pengembangan kernel, ini memungkinkan pemanggilan berantai pada pointer tetap ringkas
  • Ding sedang memverifikasi kompatibilitas paket-paket Rust yang ada menggunakan alat Crater, dan menyebut kemungkinan stabil dalam waktu 1 tahun

In-place Initialization

  • Ini adalah fitur yang mendukung makro pin_init!() yang digunakan di kernel pada level bahasa
  • Fitur ini menginisialisasi objek langsung di memori tanpa dipindahkan setelah dibuat, berguna untuk struct Pin, Future, dan trait dyn
  • Tiga proposal sedang dibahas secara paralel
    • Pendekatan keyword init: menambahkan sintaks seminimal mungkin sambil memanfaatkan trait PinInit yang sudah ada
    • Pendekatan referensi &out: menambahkan referensi tulis-saja seperti out pointer di C, mendukung inisialisasi per field
    • Pendekatan optimisasi gaya C++: objek yang akan langsung dipindahkan ke heap dibuat langsung di heap sejak awal
  • Pada akhirnya direncanakan untuk menguji pendekatan PinInit dan out-reference sekaligus guna memverifikasi kegunaan nyatanya
  • Jika fitur ini diadopsi, dampaknya diperkirakan membantu penyederhanaan struktur tidak hanya di kernel tetapi juga di seluruh kode Rust asinkron

Dampak Rust for Linux terhadap Rust

  • Kernel Linux berperan sebagai testbed yang realistis bagi perkembangan bahasa Rust
  • Ketiga fitur ini sama-sama berangkat dari kebutuhan khas kernel seperti smart pointer, memori yang dipin, dan struktur konkurensi, tetapi
    pada akhirnya pengembang Rust secara umum juga akan mendapatkan manfaatnya
  • Perubahan-perubahan ini dinilai sebagai contoh siklus saling menguatkan antara pengembangan kernel dan pengembangan bahasa

Bacaan terkait

2 komentar

 
GN⁺ 2025-10-17
Opini Hacker News

  • Saya butuh waktu cukup lama untuk membaca dan memahami dokumen RFC tentang fitur lightweight clones di Rust. Awalnya fitur ini terasa cukup menarik, tetapi pada akhirnya saya kembali merasa bahwa Rust memang bahasa yang rumit untuk dipelajari. Dari sudut pandang orang seperti saya yang belum benar-benar mempelajari Rust atau C++, kesannya seperti semua konsep dan fitur modern C++ digabung dengan unsur-unsur Haskell. Meski begitu, melihat banyak orang membuat hal-hal berguna dengan Rust, rasanya memang ada sesuatu yang benar. Jadi saya berpikir untuk mencoba serius memakai Rust lagi dalam waktu dekat. Tautan RFC terkait

    • Menurut pengalaman saya, C++ jauh lebih rumit daripada Rust. Misalnya hanya untuk cara inisialisasi saja ada 8 macam, jenis nilai pun ada 5 termasuk xvalues, belum lagi formatting dan naming convention yang tidak konsisten, rule of 5, penanganan exception, harus selalu mengecek this != other saat move assignment, perfect forwarding, SFINAE, masalah pengganti trait, dan masih banyak lagi kerumitan lainnya. Untuk memakai C++ dengan benar, kita juga harus mempelajari konvensi di atas standar yang dibangun agar bisa menulis kode dengan aman dan cepat, dan sering kali cara-cara seperti penanganan exception saling bertabrakan atau memaksa kita memilih pendekatan yang kurang ideal

    • Di komunitas Rust, suasana terhadap proposal lightweight clones ini makin lama makin negatif. Alasannya karena terlalu rumit. Bahkan dalam dokumen resmi Rust tentang arah desain, kompleksitas adalah hambatan terbesar. Bukan berarti setiap fitur yang diusulkan di Rust harus sederhana, tetapi lightweight clone hanya membuat sesuatu yang sebenarnya sudah bisa dilakukan menjadi sedikit lebih mudah, dan kalau orang sulit memahaminya, itu masalah

    • Rust terlihat sangat besar jika dilihat dari jauh, tetapi saat benar-benar dipakai menulis kode kita cepat terbiasa. Misalnya, pada awalnya saya sama sekali tidak paham konsep lifetime sehingga saya hanya menulis kode dengan Rc<>. Setelah dasar-dasarnya dikuasai lalu mempelajari lifetime lagi, semuanya jadi jauh lebih mudah. Faktanya, sebagian besar pengguna pun tidak perlu memikirkan fitur seperti lightweight clones

    • Dibanding C, ini memang sangat kompleks, tetapi dibanding C++ jauh lebih sederhana. Hampir tidak sampai perlu membongkar dokumentasi atau referensi hanya untuk memahami kode. Rust berada di posisi yang pas: "tidak terlalu rumit sampai bikin stres, dan tidak terlalu sederhana sampai kode jadi berantakan." Selain itu, secara default kodenya cenderung memiliki correctness

    • Kompleksitas Rust juga berbeda karena tidak mudah dipakai secara keliru seperti C++. Dan jika memakai clippy, ia akan otomatis menyarankan perubahan ke kode yang lebih idiomatic, jadi walaupun tidak tahu fitur baru seperti lightweight clones, kita tetap akan mendapat saran. Sebagian besar bahkan bisa diterapkan dengan mudah hanya lewat opsi --fix milik clippy. Bagian ini sangat berbeda dari C++, yang efek sampingnya justru kompleksitas terus menumpuk karena fitur yang tidak dipakai menumpuk atau dipakai dengan cara yang terlalu rumit

  • Saya melihat ada yang bilang proyek Rust for Linux sangat membantu Rust, jadi karena penasaran saya mencari file *.rs di tree kernel. Yang saya lihat, ada lapisan kompatibilitas API di bawah folder rust, dan di tree kernel hanya ada beberapa driver proof of concept yang sekadar me-rewrite driver lama (kecuali driver Nvidia yang belum selesai), jadi tampaknya hampir tidak ada yang benar-benar dipakai. Rework Rust untuk Android binder juga terasa seperti hampir sekadar tersisa. Kesan keseluruhannya seperti proyek eksperimen kecil yang lucu, dan saya jadi bertanya-tanya apakah perlu melakukan eksperimen pengembangan bahasa bersama seperti ini di source tree perangkat lunak terpenting di dunia. Rasanya lebih masuk akal melakukannya di OS yang lebih eksperimental seperti Redox

    • Driver GPU untuk Apple silicon ditulis dalam Rust, dan penulisnya sendiri mengatakan bahwa jika dikembangkan dalam C akan jauh lebih sulit. Memang belum masuk upstream, tetapi ia mengatakan, "ketika membuat driver kernel kompleks yang baru, biasanya akan muncul segala macam masalah seperti race condition, memory leak, use-after-free, dan sebagainya. Dengan Rust, masalah-masalah seperti itu hampir tidak ada dan semuanya berjalan stabil. Berkat fitur keselamatan, saya yakin driver ini thread-safe dan memory-safe, dan desainnya sendiri secara alami mengarah ke arah yang baik. Menurut saya inilah sihir Rust." Tautan pengalaman penulis Dan untuk pertanyaan apakah eksperimen seperti ini boleh dilakukan di tree kernel, disebutkan bahwa Torvalds tidak setuju dengan pandangan tersebut

    • Pendapat bahwa "rewrite Rust untuk Android binder hanya tinggal sisa-sisa" itu tidak benar. Proyek ini saat ini memang direncanakan untuk sepenuhnya menggantikan implementasi C. Artikel terkait Driver utama untuk perangkat keras Apple seri M juga ditulis dalam Rust, dan itu bukan sekadar rewrite sederhana atau proof of concept

    • Untuk membuat driver yang kompleks, sebelumnya perlu ada lapisan antarmuka. Proyek RfL sedang mengerjakan penambahan lapisan infrastruktur seperti itu ke upstream, dan fondasi itu harus dibangun dulu sebelum driver yang kompleks bisa ditulis. Redhat sedang mengerjakan nova, Asahi mengerjakan Apple GPU, dan Collabora mengerjakan ARM Mali. Jika tiga driver GPU pun tidak dianggap sebagai driver kompleks, saya jadi bertanya-tanya apa yang dianggap kompleks

    • Menanggapi klaim bahwa rewrite Rust untuk binder hanya tersisa sedikit, jika melihat pesan commit di tree Linus, tingkat penyelesaiannya sudah tinggi. Rust binder telah lulus semua pengujian binder milik Android Open Source Project, dan berbagai aplikasi serta fitur berjalan tanpa masalah berarti. Booting dan menjalankan aplikasi juga tidak bermasalah di emulator cuttlefish maupun Pixel 6 Pro. Fungsionalitasnya saat ini juga sama dengan binder C, hanya beberapa fitur debugging yang masih tersisa dan akan segera ditambahkan. Selain itu, proyek Rust for Linux memang awalnya dimulai di luar tree kernel, tetapi pada akhirnya jika ingin menguji integrasi nyata, eksperimennya memang harus dilakukan di dalam tree

    • Tujuan proyek ini bukan eksperimen kolaboratif pengembangan bahasa, melainkan memakai Rust untuk pengembangan kernel Linux. Proyek ini dimulai langsung oleh para pengembang inti yang memang ingin memakai Rust. Karena ini perangkat lunak yang sangat penting, prosesnya berjalan hati-hati dan butuh waktu untuk membangun fondasi. Bahwa Rust secara sampingan mendapat manfaat dari proyek ini hanyalah bonus

  • Dalam bagian tentang <i>field projection</i>, saya melihat di artikel bahwa kini telah diputuskan semua field pada struct akan dipin secara struktural sehingga tipe seperti Pin<&mut Field> akan selalu muncul, dan saya sadar sebelumnya saya melewatkan bagian ini. Ini memang topik yang rumit secara teknis, tetapi saya senang keputusan ini menyelesaikan masalah yang selama ini menghambat berbagai diskusi

  • Orang-orang sedang mendiskusikan <i>rancangan akhir yang terinspirasi dari C++, berupa teknik optimisasi yang diperkirakan membuat nilai baru yang langsung dipindahkan untuk dialokasikan di heap akan dibuat langsung di heap sejak awal</i>. Di sini istilah "optimisasi" berpotensi menyesatkan, jadi ada diskusi soal penggantian nama

    • Mungkin saya belum benar-benar memahami kompleksitas masalahnya, tetapi bukankah ini bisa diselesaikan dengan cukup mudah kalau kita menetapkan calling convention yang tepat? Jika ukuran struct lebih besar dari x atau ada marker type, caller tinggal memberikan buffer lewat outref dan callee langsung menulis struct itu ke buffer tersebut. Dengan begitu, meski menulis kode biasa, kita bisa mencegah alokasi heap ganda dan juga mengurangi penyalinan yang tidak perlu dalam situasi lain. Karena ini topik yang sudah mendapat banyak usaha, saya justru penasaran mengapa solusi yang diajukan malah terasa kurang nyaman

    • Menurut saya akan lebih intuitif bagi semua orang jika fitur seperti ini tidak ditangani sebagai optimisasi internal, melainkan dibuat secara eksplisit sebagai fungsi seperti new

    • Di C++, semantic seperti ini disebut elision

    • Saya mengusulkan nama seperti 'coalesced heap construction' atau 'coalesced heap allocation'

  • Setiap kali mendengar pembicaraan tentang berbagai fitur Rust, saya selalu bercanda, "asal jangan sampai kita memasukkan tokio ke kernel." Kalau nanti Rust berkembang cukup jauh dan muncul direct composition renderer sehingga aplikasi bisa berjalan di seluruh kernel, itu juga bisa jadi situasi yang cukup menarik

    • Menerapkan async runtime di dalam kernel itu sebenarnya sangat trivial. Faktanya, workqueue milik kernel sendiri pada dasarnya sudah merupakan runtime

    • Kalau itu bukan lelucon, berarti ada kesalahpahaman mendasar tentang struktur penulisan kode kernel dengan Rust (dan C). Saat menulis kode kernel, Rust seperti C stdlib berjalan dalam mode no_std, dan cargo maupun crates juga tidak bisa dipakai. Untuk memakai tokio, setengahnya harus ditulis ulang sambil mengganti seluruh interaksi dengan OS seperti socket ke cara kerja kernel

  • Menurut saya fitur-fitur Rust kali ini yang masuk untuk Linux adalah fitur awal yang benar-benar berguna secara luas untuk bahasa Rust, bukan cuma terbatas pada kernel. Saya merasa pengembangan fitur yang terlalu berpusat pada kernel sempat sedikit menghambat pengembangan fitur bahasa/pustaka lain

    • Setahu saya, systems programming memang merupakan area penerapan prioritas Rust. Interoperability itu penting di OS, embedded, atau sistem kompleks berbasis C. Fitur-fitur kali ini tampaknya memang bukan khusus kernel, melainkan utilitas umum yang sangat dibutuhkan untuk systems programming dunia nyata

    • Perkembangan untuk pengembangan kernel/firmware memang terjadi di banyak tempat, hanya saja tidak selalu jadi topik yang terus dibicarakan semua orang. Philipp terutama mendorong perubahan besar di bidang ini

    • Peran utama Rust adalah low-level systems programming. Untuk area lain, bahasa managed yang dikompilasi di userspace sering kali merupakan pilihan yang jauh lebih baik, dan pada sistem yang disusun seperti Self, Inferno, atau arsitektur Android, menurut saya tidak masalah jika Rust fokus pada fitur low-level bergaya C seperti ini

  • Fitur-fitur ini sangat keren karena dapat membantu bukan hanya kernel tetapi juga area lain, terutama generalized projections. Saya sangat senang bahwa Linux ikut mendorong perkembangan bahasa Rust

  • Saya penasaran apakah ada riset atau alat yang memanfaatkan LLM untuk secara otomatis mengonversi kode C ke Rust. Saya juga membayangkan apakah memungkinkan menyuruh LLM membuat kode Rust untuk chat, usb, i2c, driver GPU, dan sebagainya hingga bisa build/test, atau mencobanya pada proyek yang "lebih kecil" seperti sqlite, apache, atau nginx

    • Untuk riset yang bukan berbasis LLM, ada proyek c2rust dengan contoh penerapan nyata. LLM pada dasarnya masih berupa approximation, jadi tidak bisa melakukannya secara akurat dan terlalu banyak menghasilkan bug yang subtle. Tanpa dipadukan dengan sesuatu seperti formal method, ini tidak praktis. Banyak masalah juga tidak akan ditemukan hanya dengan unit test. Dan contoh proyek yang disebut sebagai "lebih kecil" itu pun sebenarnya tidak cukup kecil. Lihat contoh penerapan nyata

    • DARPA juga tertarik pada riset seperti ini dan sudah memberikan pendanaan, tetapi masih belum sampai tahap ada hasil nyata
 
ahwjdekf 2025-10-17

Penyelarasan dalam dogmatisme (alignment in dogmatism)