Rust สำหรับระบบไฟล์

 (lwn.net)
2 คะแนน โดย GN⁺ 2024-07-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การใช้ Rust กับระบบไฟล์

เป้าหมาย

  • ใช้ระบบชนิดข้อมูลของ Rust เพื่อจับข้อผิดพลาดได้มากขึ้นตั้งแต่ขั้นตอนคอมไพล์
  • เพิ่มผลิตภาพให้สูงกว่าโค้ด C ด้วยการทำงานอย่างการจัดการทรัพยากรให้เป็นอัตโนมัติ
  • ลดช่องโหว่ที่เกี่ยวข้องกับหน่วยความจำและย่นเวลาในการดีบัก

ข้อดีของ Rust

  • Rust กำจัดพฤติกรรมที่ไม่ได้กำหนดไว้ และมีความสามารถที่ช่วยให้มองเห็นว่าเกิดอะไรขึ้นภายในโค้ด
  • สามารถพิสูจน์ความถูกต้องของโค้ดที่เขียนด้วย Rust ได้ จึงลดบั๊กที่ขัดขวางการพัฒนาฟีเจอร์

ตัวอย่างของระบบชนิดข้อมูลใน Rust

  • ฟังก์ชัน iget_locked() มีข้อกำหนดที่ซับซ้อน
  • ใน Rust สามารถแทนที่ด้วยฟังก์ชัน get_or_create_inode() และใช้ระบบชนิดข้อมูลบังคับข้อกำหนดเหล่านี้ได้

การอภิปรายเรื่องการเปลี่ยนชื่อ API

  • มีปัญหาเรื่องชื่อของ C API และ Rust API ไม่ตรงกัน
  • อาจไม่คุ้นเคยสำหรับชุมชนนักพัฒนาที่มีอยู่เดิม
  • อาจจำเป็นต้องทำให้ชื่อสอดคล้องกัน

ปัญหาทั่วไป

  • ต้องตัดสินใจว่า abstraction ของ Rust จะถูกใช้ได้ทั่วไปกับระบบไฟล์ของเคอร์เนลทั้งหมด หรือจะเน้นเฉพาะระบบไฟล์แบบง่ายที่เขียนด้วย Rust
  • เมื่อโค้ด C พัฒนาไป อาจเกิดปัญหาการซิงก์กับโค้ด Rust

ปัญหาเรื่องวงจรชีวิตของอ็อบเจ็กต์

  • วงจรชีวิตของอ็อบเจ็กต์อาจแตกต่างกันไปตามระบบไฟล์
  • หากเข้ารหัสวงจรชีวิตแบบเดียวลงใน Rust API อาจทำให้บางระบบไฟล์ใช้งานไม่ได้

ปัญหาของ Rust binding

  • ไม่ใช่ทุกระบบไฟล์ที่จะย้ายไปใช้ Rust ได้ทันที
  • เมื่อโค้ด C พัฒนาไป Rust binding อาจพังได้
  • หาก Rust binding พัง ปัญหานั้นจะตกเป็นภาระของนักพัฒนา Rust-for-Linux

บทสรุป

  • เดินหน้าพัฒนา Rust binding ต่อไปพร้อมกับปล่อยให้โค้ด C พัฒนาต่อ
  • การเข้ารหัสความหมายจำนวนมากไว้ในระบบชนิดข้อมูลของ Rust จะเป็นเรื่องดีหรือไม่ดีนั้น น่าจะชัดเจนขึ้นเมื่อเวลาผ่านไป

สรุปโดย GN⁺

  • การนำ Rust มาใช้กับระบบไฟล์จะช่วยเพิ่มทั้งความปลอดภัยของหน่วยความจำและผลิตภาพได้มาก
  • ระบบชนิดข้อมูลของ Rust สามารถบังคับข้อกำหนด API ที่ซับซ้อนได้ จึงช่วยเพิ่มความถูกต้องของโค้ด
  • หากนักพัฒนา C เดิมไม่เรียนรู้ Rust ก็อาจเกิดความยากลำบาก เช่น ปัญหาการซิงก์
  • หาก Rust binding พัง การแก้ไขจะเป็นหน้าที่ของนักพัฒนา Rust-for-Linux
  • โครงการที่มีความสามารถคล้ายกันมีเช่น Fuchsia OS ของ Google

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-16
ความคิดเห็นใน Hacker News

  • การจัดการด้วยฟังก์ชันเดียวทั้งที่แต่ละไฟล์ซิสเต็มดูแลวงจรชีวิตของ inode ต่างกันนั้นขัดกับแนวคิดของชั้นนามธรรม

    • ควรจัดการวงจรชีวิตของ inode แยกตามไฟล์ซิสเต็ม

  • มีคำถามว่า Rust จำเป็นต้องเปลี่ยนแปลงเพื่อให้เรียก C ได้ง่ายขึ้นหรือไม่

    • สะท้อนว่ายังขาดความเข้าใจที่ชัดเจนเกี่ยวกับการทำงานร่วมกันระหว่าง Rust กับ C
    • C++ และ Objective C แค่ include header file แล้วเรียกฟังก์ชันได้เลย
    • Swift สามารถ include ไฟล์ Objective C แล้วเรียก C ได้
    • แทนที่ Rust จะต้องปรับให้เข้ากับนักพัฒนาเคอร์เนล ฝั่งภาษาก็ควรยืดหยุ่นขึ้นอีกเล็กน้อย

  • ยังไม่ชัดเจนว่า Rust API เป็นการห่อ C API หรือเป็นการเขียนขึ้นใหม่

    • ถ้าเป็นการเขียนใหม่ การใช้ชื่อเดียวกับ C API อาจทำให้เกิดปัญหาได้

  • การเพิ่ม Rust เข้าไปในเคอร์เนลทำให้เกิดความซับซ้อนเพิ่มเติม

    • ถ้าเขียน OS ใหม่ตั้งแต่ต้น ก็สามารถใช้ความสามารถของภาษาได้ทั้งหมด
    • แต่เมื่อเพิ่มเข้าไปในโค้ดเบสขนาดใหญ่ที่มีอยู่แล้ว ก็จะเกิดปัญหาเพิ่มขึ้น

  • การถกเถียงเป็นไปอย่างมีอารยธรรมมาก

    • ไม่เห็นด้วยกับโทนเชิงลบ
    • มองในแง่ดีที่ผู้เกี่ยวข้องสื่อสารปัญหาออกมาได้อย่างชัดเจน

  • การมีตัวเลือกมากขึ้นใน Linux kernel เป็นเรื่องที่มีประโยชน์เสมอ

    • Rust ไม่ใช่คำตอบของทุกปัญหา
    • Rust มอบโมเดลการเขียนโปรแกรมที่ปลอดภัย แต่ก็มีข้อจำกัด
    • ปัญหาหน่วยความจำ? ใช้ Rust!
    • ปัญหาคอนเคอร์เรนซี? ย้ายไป Rust!
    • แต่จะทำทุกอย่างที่ C ทำได้โดยไม่ใช้ unsafe block ไม่ได้
    • Rust อาจมอบมุมมองใหม่ได้ แต่ไม่ใช่ทางออกแบบสมบูรณ์

  • คอมเมนต์บางส่วนด้านล่างหน้าของ lwn.net หยาบคาย

    • ลองนึกภาพการพูดกับคนที่มีส่วนร่วมในโปรเจกต์โอเพนซอร์สว่า "วิทยาศาสตร์ก้าวหน้าด้วยงานศพทีละครั้ง"

  • มีการถกเถียงเรื่องชื่อของ C API กับ Rust API ที่ไม่สอดคล้องกัน

    • ความยากของธรรมเนียมการตั้งชื่อแบบเลกาซี
    • จะคงชื่อเดิมไว้หรือห่อด้วยชื่อใหม่ก็ได้
    • การตั้งชื่อเป็นเรื่องยาก