Rust untuk Sistem Berkas

Menggunakan Rust untuk sistem berkas

Tujuan

• Menggunakan sistem tipe Rust untuk menangkap lebih banyak kesalahan saat waktu kompilasi
• Meningkatkan produktivitas dibandingkan kode C dengan mengotomatiskan pekerjaan seperti pembersihan sumber daya
• Mengurangi kerentanan terkait memori dan mempersingkat waktu debugging

Kelebihan Rust

• Rust menghilangkan perilaku yang tidak terdefinisi dan menyediakan kemampuan untuk melihat apa yang sedang terjadi di dalam kode
• Kebenaran kode yang ditulis dengan Rust dapat dibuktikan, sehingga bug yang menghambat pengembangan fitur berkurang

Contoh sistem tipe Rust

• Fungsi iget_locked() memiliki persyaratan yang kompleks
• Di Rust, ini dapat digantikan dengan fungsi get_or_create_inode(), dan persyaratan tersebut ditegakkan melalui sistem tipe

Diskusi tentang perubahan nama API

• Ada masalah ketidaksesuaian nama antara API C dan API Rust
• Hal ini mungkin terasa tidak familier bagi komunitas pengembang yang sudah ada
• Menyamakan nama mungkin diperlukan

Masalah umum

• Perlu diputuskan apakah abstraksi Rust akan digunakan secara umum pada semua sistem berkas kernel, atau hanya difokuskan pada sistem berkas sederhana yang ditulis dengan Rust
• Saat kode C berevolusi, bisa muncul masalah sinkronisasi dengan kode Rust

Masalah siklus hidup objek

• Siklus hidup objek dapat berbeda-beda tergantung sistem berkasnya
• Jika satu siklus hidup tunggal dienkodekan ke dalam API Rust, hal itu mungkin tidak akan bekerja pada beberapa sistem berkas

Masalah pada binding Rust

• Tidak semua sistem berkas akan langsung beralih ke Rust
• Saat kode C berevolusi, binding Rust bisa rusak
• Jika binding Rust rusak, hal itu akan tetap menjadi masalah bagi para pengembang Rust-for-Linux

Kesimpulan

• Pengembangan binding Rust dilanjutkan sambil membiarkan kode C terus berevolusi
• Apakah mengodekan banyak makna ke dalam sistem tipe Rust itu baik atau buruk akan menjadi lebih jelas seiring waktu

Ringkasan GN⁺

• Mengadopsi Rust ke sistem berkas akan sangat membantu meningkatkan keamanan memori dan produktivitas
• Melalui sistem tipe Rust, persyaratan API yang kompleks dapat ditegakkan sehingga meningkatkan kebenaran kode
• Jika para pengembang C yang sudah ada tidak mempelajari Rust, kesulitan seperti masalah sinkronisasi dapat muncul
• Jika binding Rust rusak, penyelesaiannya akan menjadi tanggung jawab para pengembang Rust-for-Linux
• Proyek dengan fungsi serupa antara lain Fuchsia OS dari Google

[GN⁺]

Komentar Hacker News

• Karena setiap file system mengelola siklus hidup inode secara berbeda, mengelolanya dengan fungsi yang sama justru bertentangan dengan lapisan abstraksi

  • Siklus hidup inode harus dikelola per file system

• Ada pertanyaan apakah Rust perlu diubah agar lebih mudah melakukan pemanggilan C

  • Masih kurang pemahaman yang jelas tentang interoperabilitas Rust dan C
  • Di C++ dan Objective C, cukup sertakan header file lalu panggil fungsinya
  • Swift dapat menyertakan file Objective C dan memanggil C
  • Daripada Rust menyesuaikan diri dengan pengembang kernel, bahasanya sendiri mungkin perlu menjadi sedikit lebih fleksibel

• Tidak jelas apakah API Rust membungkus C API atau mengimplementasikannya ulang

  • Jika itu implementasi ulang, menggunakan nama yang sama dengan C API dapat menimbulkan masalah

• Menambahkan Rust ke kernel menyebabkan kompleksitas tambahan

  • Jika menulis OS baru dari nol, semua fitur bahasa bisa digunakan
  • Jika menambahkannya ke codebase lama yang sangat besar, akan muncul masalah tambahan

• Diskusinya sangat beradab

  • Tidak setuju dengan nada yang negatif
  • Optimistis karena orang-orang yang terlibat menyampaikan masalahnya dengan jelas

• Lebih banyak opsi di kernel Linux selalu bermanfaat

  • Rust bukan solusi untuk semua masalah
  • Rust menyediakan model pemrograman yang aman, tetapi terbatas
  • Masalah memori? Pakai Rust!
  • Masalah konkurensi? Beralih ke Rust!
  • Tetapi tanpa menggunakan blok unsafe, Rust tidak bisa melakukan semua hal yang bisa dilakukan C
  • Rust dapat menawarkan sudut pandang baru, tetapi bukan solusi yang sepenuhnya lengkap

• Beberapa komentar di bagian bawah halaman lwn.net bersikap tidak sopan

  • Bayangkan menulis komentar seperti "sains maju satu pemakaman pada satu waktu" kepada orang yang berkontribusi pada proyek open source

• Ada pembahasan tentang masalah ketidaksesuaian nama antara C API dan Rust API

  • Sulitnya konvensi penamaan lama
  • Bisa mempertahankan nama yang sama atau membungkusnya dengan nama baru
  • Memberi nama memang pekerjaan yang sulit