การทดลองใช้ Rust ในเคอร์เนล Linux สิ้นสุดลงแล้ว (และประสบความสำเร็จ)

 (lwn.net)
17 คะแนน โดย GN⁺ 2025-12-11 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • งาน ผสานรวม Rust ภายในเคอร์เนล Linux ได้สิ้นสุดระยะทดลอง และได้รับการยอมรับให้เป็น องค์ประกอบอย่างเป็นทางการ
  • ในงาน Maintainers Summit ประจำปี นักพัฒนาได้ตกลงร่วมกันว่าจะรับรองการรองรับ Rust เป็น ความสามารถถาวร
  • ด้วยเหตุนี้ แท็ก ‘experimental’ ในโค้ดที่เกี่ยวข้องกับ Rust ภายในเคอร์เนลจะถูกนำออก
  • บรรณาธิการของ LWN ระบุว่า “การทดลองจบลงแล้ว และมันประสบความสำเร็จ” พร้อมกล่าวถึง ผลงานของทีม Rust for Linux
  • เรื่องนี้ถูกประเมินว่าเป็น จุดเปลี่ยนสำคัญ ของการขยายภาษาที่ใช้พัฒนาเคอร์เนล และทิศทางสู่ ความปลอดภัยและความทันสมัย

การสิ้นสุดของการทดลอง Rust ในเคอร์เนลและการรับรองอย่างเป็นทางการ

  • ในงาน Maintainers Summit ประจำปี มีการหารือเรื่องการรองรับ Rust ภายในเคอร์เนล และนักพัฒนาที่เข้าร่วมได้เห็นพ้องกันว่า Rust ไม่ใช่ความสามารถเชิงทดลองอีกต่อไป
    • ตอนนี้ Rust ได้กลายเป็น ส่วนสำคัญของเคอร์เนล แล้ว
    • ดังนั้น เครื่องหมาย ‘experimental’ ในโค้ดที่เกี่ยวข้องจะถูกลบออก
  • บรรณาธิการของ LWN ระบุไว้อย่างชัดเจนในโพสต์ว่า “การทดลองจบลงแล้ว และมันประสบความสำเร็จ”
    • พร้อมส่ง ข้อความแสดงความยินดี ไปยังความทุ่มเทของทีม Rust for Linux

ปฏิกิริยาจากชุมชน

  • ชื่อโพสต์ทำให้เกิดความเข้าใจผิดอยู่ช่วงหนึ่ง จนผู้อ่านบางส่วน เข้าใจว่า Rust ถูกถอดออก
    • มีหลายความเห็นตามมาว่า “เกือบโดนหลอกแล้ว”, “อารมณ์ขึ้นลงเหมือนนั่งรถไฟเหาะ” เป็นต้น
  • ผู้ใช้บางรายตอบสนองเชิงขำขันโดยกล่าวถึงสไตล์พาดหัวของ Phoronix
    • พร้อมทั้งเห็นว่ากิจกรรม การทำเบนช์มาร์กและอัปเดตระบบนิเวศโอเพนซอร์ส ของ Phoronix มีประโยชน์
  • ความเห็นอื่น ๆ กล่าวถึงว่า Microsoft ก็กำลัง นำ Rust เข้าสู่เคอร์เนล Windows เช่นกัน
    • มีความเห็นว่าบางองค์ประกอบถูกเขียนด้วย Rust แล้ว และ รวมอยู่ในขั้นตอนการจัดส่ง เรียบร้อย

ความหมายของการนำ Rust มาใช้

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

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

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

 
secret3056 2025-12-12

ถ้าเป็นอย่างนั้น ก็ไม่ได้มีผู้ดูแลหลายคนถอนตัวไปแล้วหรือครับ?
 
bus710 2025-12-12

มีหนังสือเกี่ยวกับเรื่องนี้ที่เป็นภาษาเกาหลีออกมาเพียงเล่มเดียว แต่ก็น่าเสียดายที่แนวทางการใช้ Rust ใน Linux kernel มีการเปลี่ยนแปลงแบบ breaking change หลายครั้ง จนไม่สามารถใช้งานร่วมกับเคอร์เนลยุคปัจจุบันได้อย่างสมบูรณ์ หากมีการช่วยกันเสริมข้อมูลผ่าน GitHub หรือช่องทางอื่น ๆ ก็คงจะดีมากครับ
 
GN⁺ 2025-12-11
ความคิดเห็นจาก Hacker News

  • การรองรับ Rust พัฒนาไปมากจริง ๆ ในช่วง 2 ปีที่ผ่านมา
    ตอนนี้แทบจะเขียนเคอร์เนลโมดูลได้โดยแทบไม่ต้องมี boilerplate แล้ว
    คิดว่าการเอาแท็ก “experimental” ออกเป็นหมุดหมายสำคัญครั้งใหญ่
    ต่อจากนี้วันที่ดิสโทรต่าง ๆ ออกเคอร์เนลที่เปิดใช้การรองรับ Rust เป็นค่าปริยาย น่าจะเป็น จุดเปลี่ยน ที่แท้จริง

    • บางดิสโทรทำแบบนั้นอยู่แล้ว
      ตัวอย่างเช่น NixOS และ Arch เปิดใช้ หน้าจอ kernel panic พร้อม QR code ที่เขียนด้วย Rust
      และคิดว่า Fedora ก็น่าจะรองรับด้วย
    • เท่าที่ทราบ Fedora 43 คอมไพล์มาพร้อม CONFIG_RUST=y
    • สงสัยว่าวลี “เคอร์เนลที่เปิดใช้การรองรับ Rust เป็นค่าปริยาย” หมายถึงอะไรกันแน่
      ไม่ได้หมายความว่าเคอร์เนลรองรับ Rust ใน user space แต่หมายถึงเพียงว่ามีโค้ดบางส่วนของเคอร์เนลที่คอมไพล์ด้วย rustc
    • จนกว่า Rust จะรองรับใน GCC อย่างสมบูรณ์ ก็ยังสงสัยว่าจะทำได้บนทุกแพลตฟอร์มหรือไม่

  • หลังจากมีแรงต้านมานาน การที่ Rust ถูก รับรองอย่างเป็นทางการ ใน Linux kernel เป็นเรื่องน่าปลื้มใจ
    ขอปรบมือให้ทีม Rust for Linux

    • จำได้ว่าเมื่อก่อนมีความวุ่นวายเกี่ยวกับโค้ด Rust ของโครงการ Asahi เพราะ ผู้ดูแลไม่ยอมรับ
      เลยสงสัยว่าเหตุการณ์นั้นเป็นโดมิโนตัวแรกของโครงการหรือเปล่า
    • ตาม บทความของ Phoronix
      Alex Gaynor ซึ่งเคยเป็นผู้ดูแลร่วมของ Rust for Linux ได้ถอนตัวอย่างเป็นทางการแล้ว
      ตอนนี้ Miguel Ojeda เป็นผู้ดูแลอย่างเป็นทางการเพียงคนเดียว และมีผู้รีวิวโค้ดหลายคน

  • สงสัยว่าการเอาแท็ก “experimental” ออก หมายความว่าผู้ดูแลทุกคนถูก บังคับ ไม่ให้ทำโค้ด Rust พังหรือไม่

    • ในทางปฏิบัติมันเป็นเพียง สัญญาณว่า Rust ตั้งหลักในเคอร์เนลได้แล้ว
      เป็นการสร้างความมั่นใจให้นักพัฒนาว่าสามารถลงทุนกับไดรเวอร์ที่เขียนด้วย Rust ได้
      กฎยังเหมือนเดิม และโค้ดที่ทำให้การบิลด์ Rust พังจะส่งให้ Linus ไม่ได้
    • ภายในเคอร์เนลไม่มีการรับประกันเสถียรภาพ ยกเว้น API สำหรับ user space
      นั่นคือหากผู้ดูแลทำโค้ด Rust ภายในพัง ก็ไม่ได้ถือว่าผิดกฎ

  • สงสัยว่าสถาปัตยกรรมที่ Rust ยังไม่รองรับจะถูก ทิ้ง ไปเลยหรือไม่

    • ไม่ใช่แบบนั้น ตอนนี้ Rust ใช้อยู่แค่ใน ซับซิสเต็มไดรเวอร์
      ส่วนหลักแกนของเคอร์เนลยังต้องเขียนด้วย C
    • สงสัยว่ามีสถาปัตยกรรมไหนบ้างที่ยังไม่รองรับ
    • มีการเล่นมุกว่าก็ใช่ “สุกหมดแล้ว (cooked)”

  • มีคนบอกว่าชื่อบทความถูกแก้เป็น “The (successful) end of the kernel Rust experiment”
    เพราะคอมมูนิตี้ให้ฟีดแบ็กว่าชื่อเดิมเว่อร์เกินไป

    • คิดว่าชื่อที่แก้แล้วเหมาะสมดี
      ตาม กฎของ Hacker News
      ระบุว่า “ให้แก้ชื่อเดิม เฉพาะเมื่อทำให้เข้าใจผิด เท่านั้น”
    • คำว่า “successful” เหมือนจะถูกสื่ออยู่แล้ว
      เพราะการทดลองที่ล้มเหลวจะไม่ถูกบอกว่าสิ้นสุด
    • มีการเสนอชื่อแนวขำ ๆ ว่า “Linux devs tried Rust — you won’t BELIEVE the reaction!”

  • เมื่อมีคนถามว่า “นี่เป็นเรื่องใหญ่ไหม?”

    • มีคนตอบว่า “ใช่สิ มีการเพิ่ม dependency ก้อนใหญ่ เข้ามา”
    • อีกคนก็ตอบสั้น ๆ ว่า “ใช่”

  • ถ้าแนวโน้มคือไดรเวอร์ของ Linux kernel กำลังไปทาง Rust ก็สงสัยว่าฝั่ง BSD อย่าง FreeBSD จะเกิด การ oxidation แบบเดียวกันหรือไม่
    หรือจะเกิดแรงต้านและการแยกทาง ก็น่าจับตาดู

  • เป็นฝ่ายที่ยินดีกับการลองสิ่งใหม่ ๆ

    • แต่ก็มีคนโต้ว่า “ของใหม่ไม่เสถียรและเรียนรู้ยาก”
      อย่างไรก็ดีคิดว่า Rust คุ้มค่ากับความยากนั้น เพราะมี ความปลอดภัยด้านหน่วยความจำ และความสามารถในการแสดงออกของภาษา

  • สงสัยว่าตอนนี้มีส่วนไหนของเคอร์เนลที่เขียนด้วย Rust บ้าง

    • ตัวอย่างเด่นคือ DRM Panic “Screen of Death” ที่เขียนด้วย Rust
      ดู บทความของ Phoronix
    • ตอนนี้ Rust ถูกใช้หลัก ๆ ฝั่งไดรเวอร์ GPU

  • สงสัยว่าในโค้ด Rust ของเคอร์เนลมี unsafe อยู่มากแค่ไหน
    เมื่อก่อนมีคนบ่นเยอะว่า unsafe ใช้งานลำบากเกินไป

    • unsafe ส่วนใหญ่อยู่ซ่อนภายใน kernel crate ที่ใช้โต้ตอบกับ C API
      นักพัฒนาไดรเวอร์แทบไม่จำเป็นต้องใช้ unsafe เอง
    • โดยหลักแล้ว unsafe ถูกออกแบบให้ใช้เฉพาะใน โค้ดขอบเขตการเชื่อมต่อ (edge) เท่านั้น
      โค้ดส่วนใหญ่เขียนเป็น safe Rust
    • unsafe ยังยากอยู่ก็จริง แต่ในโค้ดไดรเวอร์จริงแทบไม่ค่อยโผล่มา
      ตัวอย่างเช่น pwm_th1520.rs
      มี unsafe แค่บรรทัดเดียวเพื่อรองรับ Send และ Sync
    • หลักการคือควรทำเอกสารให้ unsafe block และครอบมันไว้ด้วยอินเทอร์เฟซที่ปลอดภัย เพื่อที่จะไม่ต้องเห็นมันตรง ๆ อีก