ชุมชนเทคโนโลยีกำลังหึ่งไหวกับการถกเถียงเกี่ยวกับ Asterinas ซึ่งเป็นเคอร์เนลใหม่ที่เข้ากันได้กับ Linux เขียนด้วยภาษา Rust และนำเสนอสถาปัตยกรรม framekernel แบบใหม่ แม้ว่าโปรเจกต์นี้จะมุ่งหวังที่จะรวมจุดเด่นของการออกแบบแบบ monolithic และ microkernel เข้าด้วยกัน แต่สมาชิกชุมชนกำลังตั้งคำถามสำคัญเกี่ยวกับความเป็นไปได้ในทางปฏิบัติและแนวทางเทคนิคของมัน
ข้อมูลจำเพาะทางเทคนิคของ Asterinas
- ภาษา: Rust พร้อมสถาปัตยกรรม framekernel
- ความเข้ากันได้: เข้ากันได้กับ Linux ABI
- ใบอนุญาต: Mozilla Public License (MPL) 2.0
- สถาปัตยกรรม: แบ่งออกเป็นเฟรมเวิร์กที่มีสิทธิพิเศษ (unsafe Rust) และบริการที่ไม่มีสิทธิพิเศษ (safe Rust)
- กรณีการใช้งานเป้าหมาย: เน้นไปที่ Confidential VMs และสภาพแวดล้อมเสมือนในเบื้องต้น
- ไทม์ไลน์การพัฒนา: มีเป้าหมายที่จะรองรับบริการในโลกแห่งความเป็นจริงภายในหนึ่งปี
การพัฒนา Driver ยังคงเป็นความท้าทายสูงสุด
การถกเถียงที่ร้อนแรงที่สุดมุ่งเน้นไปที่การรองรับ device driver ซึ่งหลายคนมองว่าเป็นปัจจัยสำคัญที่จะกำหนดความสำเร็จหรือล้มเหลวของเคอร์เนลใหม่ใดๆ สมาชิกชุมชนชี้ไปที่ข้อสังเกตที่มีวิสัยทัศน์ของ Linus Torvalds จากหลายทศวรรษที่ผ่านมาเกี่ยวกับการพัฒนา driver ที่เป็นเหมือนคูน้ำป้องกันของ Linux ความท้าทายไม่ใช่แค่การแปลทางเทคนิคเท่านั้น แต่เป็นเรื่องของการทดสอบฮาร์ดแวร์และการบำรุงรักษา
นักพัฒนาคนหนึ่งเน้นย้ำถึงจุดคอขวดที่สำคัญ: แม้แต่การแปลโดยวิศวกรที่มีทักษะก็อาจมีปัญหาหากพวกเขาไม่มีฮาร์ดแวร์จริงในการทดสอบ ปัญหาการทดสอบนี้จะซับซ้อนยิ่งขึ้นเมื่อพิจารณาถึงฮาร์ดแวร์แปลกๆ ที่ไม่เป็นมาตรฐานซึ่งแทบจะทำงานกับ driver ของ Windows ที่มีอยู่ไม่ได้ นับประสาอะไรกับ driver ที่ถูกพอร์ตใหม่
ชุมชนกำลังสำรวจวิธีแก้ปัญหาที่สร้างสรรค์ รวมถึงการแปล driver ด้วยความช่วยเหลือของ AI และแนวทางการจำลองเสมือนที่คล้ายกับการใช้ User-Mode Linux ของ HongMeng kernel อย่างไรก็ตาม ข้อกังวลเรื่องใบอนุญาตเกิดขึ้นเนื่องจาก Linux driver ที่ถูกพอร์ตจะต้องรักษาใบอนุญาต GPLv2
ปรัชญาการออกแบบ Framekernel ถูกตรวจสอบอย่างละเอียด
แนวทางของ Asterinas ในการแบ่งโค้ดเคอร์เนลออกเป็นส่วนประกอบที่มีสิทธิพิเศษ (unsafe Rust) และไม่มีสิทธิพิเศษ (safe Rust) ได้สร้างความสับสนและการถกเถียง คำศัพท์ในตอนแรกดูเหมือนจะย้อนแย้งกับนักพัฒนาหลายคน ซึ่งคาดหวังการแยกสิทธิพิเศษแบบดั้งเดิมระหว่าง kernel space และ user space
นักพัฒนาหลักของโปรเจกต์ได้ชี้แจงว่านี่หมายถึงสิทธิพิเศษของภาษา Rust มากกว่าสิทธิพิเศษของฮาร์ดแวร์ - framework ที่มีสิทธิพิเศษสามารถใช้ฟีเจอร์ unsafe Rust ได้ ในขณะที่บริการที่ไม่มีสิทธิพิเศษต้องยึดติดกับ safe Rust การออกแบบนี้มุ่งหวังที่จะลดฐานการคำนวณที่เชื่อถือได้ให้น้อยที่สุด ในขณะที่รักษาทุกอย่างไว้ใน kernel space เพื่อประสิทธิภาพ
Framekernel เทียบกับสถาปัตยกรรมแบบดั้งเดิม
| สถาปัตยกรรม | ตำแหน่งโค้ด | ประสิทธิภาพ | ความปลอดภัย | ความซับซ้อน |
|---|---|---|---|---|
| Monolithic | พื้นที่ Kernel | สูง | ต่ำ (ไม่ปลอดภัยทั้งหมด) | ปานกลาง |
| Microkernel | แยก kernel/user | ต่ำกว่า (ค่าใช้จ่าย IPC) | สูง (การแยกส่วน) | สูง |
| Framekernel | พื้นที่ Kernel (แยกตามตรรกะ) | สูง (หน่วยความจำร่วม) | ปานกลาง (APIs ปลอดภัย) | ปานกลาง |
ตำนานประสิทธิภาพ Microkernel ยังคงอยู่
ส่วนสำคัญของการถกเถียงหมุนรอบการรับรู้ที่ล้าสมัยเกี่ยวกับประสิทธิภาพ microkernel สมาชิกชุมชนหลายคนโต้แย้งว่า microkernel สมัยใหม่อย่าง seL4 ได้แก้ปัญหาประสิทธิภาพ IPC ที่รบกวนการออกแบบในยุคแรกๆ ไปแล้วส่วนใหญ่ ความซับซ้อนของฮาร์ดแวร์สมัยใหม่ที่มี syscall ที่แพงและความสำเร็จของกลไกคิวอย่าง io_uring บ่งชี้ว่าช่องว่างประสิทธิภาพระหว่างการออกแบบแบบ monolithic และ microkernel อาจมีความเกี่ยวข้องน้อยกว่าที่เคยคิดไว้
ผลประโยชน์ด้านประสิทธิภาพที่คาดหวังจาก monolithic kernel ถูกสูญเสียไปกับฟีเจอร์ที่เลียนแบบฟีเจอร์ microkernel
อย่างไรก็ตาม คนอื่นๆ ยังคงยืนยันว่าการปรับใช้ในทางปฏิบัติยังคงท้าทาย โดยชี้ไปที่การนำไปใช้ในโลกจริงที่จำกัดของการออกแบบ microkernel นอกเหนือจากกรณีการใช้งานเฉพาะทาง
Virtualization เปลี่ยนเกม
มุมมองที่น่าสนใจเกิดขึ้นรอบความสำคัญที่ลดลงของการรองรับ driver แบบ bare-metal ในโลกที่เป็น virtual ในปัจจุบัน นักพัฒนาหลายคนสังเกตว่า Linux instance ส่วนใหญ่ที่พวกเขาโต้ตอบด้วยทำงานแบบ virtualized ไม่ว่าจะเป็นในสภาพแวดล้อม cloud, container หรือ VM ในเครื่อง การเปลี่ยนแปลงนี้อาจให้เส้นทางการนำไปใช้ที่เป็นไปได้มากขึ้นแก่ Asterinas โดยมุ่งเน้นไปที่สภาพแวดล้อม virtualized ที่ความหลากหลายของ driver มีความสำคัญน้อยกว่า
ทีมโปรเจกต์กำลังมุ่งเป้าไปที่แนวทางนี้แล้ว โดยมีแผนที่จะใช้ Asterinas เป็น guest OS ใน Confidential VM ที่ข้อได้เปรียบด้านความปลอดภัยจาก memory safety และฐานการคำนวณที่เชื่อถือได้ขนาดเล็กจะมีค่ามากกว่าการรองรับฮาร์ดแวร์ที่ครอบคลุม
ข้อกังวลเรื่องใบอนุญาตและระบบนิเวศ
การเลือกใช้ Mozilla Public License (MPL) 2.0 แทน GPL ได้รับปฏิกิริยาที่หลากหลายจากชุมชน แม้ว่าทีมโปรเจกต์จะได้จัดทำเอกสารเหตุผลของพวกเขาแล้ว แต่นักพัฒนาบางคนแสดงความชอบใบอนุญาต copyleft ที่เข้มงวดมากกว่า การตัดสินใจเรื่องใบอนุญาตนี้อาจส่งผลต่อรูปแบบการนำไปใช้และการมีส่วนร่วมเมื่อเปรียบเทียบกับทางเลือกที่ใช้ใบอนุญาต GPL
โปรเจกต์แสดงให้เห็นความหวังสำหรับกรณีการใช้งานเฉพาะทาง โดยเฉพาะอย่างยิ่งในสภาพแวดล้อม virtualized ที่เน้นความปลอดภัย อย่างไรก็ตาม เส้นทางสู่การนำไปใช้ในวัตถุประสงค์ทั่วไปยังคงท้าทาย โดยการพัฒนาระบบนิเวศ driver น่าจะเป็นตัวกำหนดความสำเร็จหรือล้มเหลวขั้นสุดท้ายในตลาดที่กว้างขึ้น