MotorOS: ระบบปฏิบัติการที่สร้างด้วย Rust สำหรับ x64 VM

 (github.com/moturus)
12 คะแนน โดย GN⁺ 2024-01-09 | 3 ความคิดเห็น | แชร์ทาง WhatsApp

แนะนำ Motūrus OS

  • โปรเจกต์ Motūrus กำลังพัฒนา MotūrusOS ซึ่งเป็นระบบปฏิบัติการที่เรียบง่าย รวดเร็ว และปลอดภัยสำหรับคลาวด์
  • Motūrus OS เป็นระบบปฏิบัติการแบบใหม่ที่มุ่งเป้าไปที่เวิร์กโหลดบนพื้นฐานของเครื่องเสมือน โดยใช้กับเว็บเซิร์ฟเวอร์ เซิร์ฟเวอร์เลส เอดจ์แคชชิง และงานลักษณะใกล้เคียงกัน

ทำไมต้อง Motūrus OS?

  • ปัจจุบัน เวิร์กโหลดโปรดักชันที่ทำงานแบบเสมือนจริงส่วนใหญ่ยังรันอยู่บน Linux
  • แม้ Linux จะมีความสามารถขั้นสูงมากมาย แต่ก็มีความซับซ้อนบางอย่างที่ไม่เหมาะกับเวิร์กโหลดแบบเสมือนจริง:
    • Linux ถูกปรับแต่งมาเพื่อ bare metal จึงไม่มีประสิทธิภาพนักเมื่อนำมาใช้ภายใน VM
    • Linux ใช้งานได้ยาก
    • ในเชิงประวัติศาสตร์ Linux ไม่ได้มีความปลอดภัยสูงนัก
  • หากมีระบบปฏิบัติการใหม่ที่โฟกัสกับเวิร์กโหลดแบบเสมือนจริง ก็สามารถทำให้เรียบง่ายและปลอดภัยกว่า Linux ได้มาก และอาจเทียบเท่าหรือเหนือกว่า Linux ในด้านประสิทธิภาพและความคุ้มค่า

Motūrus OS คืออะไร?

  • Motūrus OS เป็นระบบปฏิบัติการแบบไมโครเคอร์เนล สร้างด้วยภาษา Rust และออกแบบมาเพื่อรองรับเฉพาะเวิร์กโหลดแบบเสมือนจริงเท่านั้น
  • ขณะนี้รองรับเครื่องเสมือนที่ใช้ x64 KVM และสามารถรันบน Qemu หรือ Cloud Hypervisor ได้
  • Rust เป็นภาษาหลักของ Motūrus OS โดยใช้ทั้งในการพัฒนาและใน ABI ด้วย

ฟีเจอร์ที่ใช้งานได้แล้ว

  • ปัจจุบันซับซิสเต็มส่วนใหญ่ยังอยู่ในสถานะ POC/MVP แต่สามารถรันงานอย่างเว็บเซิร์ฟเวอร์ได้แล้ว
  • โดยเฉพาะอย่างยิ่ง ฟีเจอร์ต่อไปนี้ใช้งานได้:
    • บูตได้ภายในประมาณ 200ms ผ่าน MBR(Qemu) หรือ PVH(Cloud Hypervisor)
    • ไมโครเคอร์เนล himem
    • การจัดตารางงาน: round-robin แบบมัลติโปรเซสเซอร์อย่างง่าย (SMP) และการจัดตารางงานของเคอร์เนลเป็นแบบ cooperative
    • การจัดการหน่วยความจำ: ขณะนี้รองรับเฉพาะหน้าเพจ 4K, stack มีการป้องกัน, และ page fault ใน user space ถูกจัดการได้อย่างเหมาะสม
    • ซับซิสเต็ม I/O (ภายใน user space): ไดรเวอร์ VirtIO-BLK และ VirtIO-NET, ระบบไฟล์แบบง่าย 2 แบบ, และเครือข่ายที่อิงบน smoltcp (รองรับเฉพาะ TCP)
    • user space: รองรับหลายโปรเซส, preemption, เธรด, TLS และมีการพอร์ต Rust standard library มาแล้วเป็นส่วนใหญ่
    • มีเชลล์สไตล์ Unix แบบง่ายให้ใช้งาน

ฟีเจอร์ที่ยังใช้งานไม่ได้

  • ส่วนใหญ่ของระบบยังไม่พร้อมสำหรับการใช้งานจริงในโปรดักชัน
  • ยังไม่ได้ผ่านการตรวจสอบด้านความปลอดภัย
  • ใน sys-io (ซับซิสเต็ม I/O ใน user space) ยังสามารถเจอ panic แบบ "unimplemented" ได้ง่าย
  • โดยเฉพาะอย่างยิ่ง ฟีเจอร์ต่อไปนี้ยังใช้งานไม่ได้:
    • ระบบไฟล์: API ส่วนใหญ่ของ Rust std::fs ถูกทำไว้เป็น POC แล้ว แต่จำเป็นต้องเขียนใหม่ให้ใช้ asynchronous I/O
    • เครือข่าย: std::net::TcpStream ถูกพัฒนาไว้เกือบครบแล้ว แต่โปรโตคอลอื่นยังไม่ได้รองรับ
    • ecosystem นอกเหนือจาก Rust standard: บาง crate สามารถคอมไพล์และใช้งานได้ด้วยการปรับเล็กน้อย แต่ crate ที่พึ่งพา asynchronous runtime เช่น Tokio ยังไม่สามารถคอมไพล์ได้ในตอนนี้

จะ build/run Motūrus OS ได้อย่างไร?

  • ดูเอกสาร docs/build.md

คำขอบคุณ

  • ขอขอบคุณ Philipp Oppermann อย่างมากสำหรับบล็อกซีรีส์เกี่ยวกับการเขียน OS ด้วย Rust ซึ่งเป็นแรงบันดาลใจให้ผู้คนจำนวนมากได้ทดลองในสายงานนี้

ความเห็นของ GN⁺

  • แนวทางที่น่าสนใจ: Motūrus OS เป็นระบบปฏิบัติการใหม่ที่ออกแบบมาเฉพาะสำหรับสภาพแวดล้อมแบบเสมือนจริง โดยตั้งใจแก้ปัญหาความซับซ้อนและความไม่มีประสิทธิภาพของ Linux
  • การเลือกใช้ภาษา Rust: Rust เป็นภาษาที่ให้ความสำคัญกับ memory safety และประสิทธิภาพ ซึ่งน่าจะช่วยเสริมทั้งความปลอดภัยและประสิทธิผลของ Motūrus OS
  • การมีส่วนต่อชุมชนนักพัฒนา: โปรเจกต์นี้อาจช่วยให้นักพัฒนาที่สนใจด้านการพัฒนาระบบปฏิบัติการได้สำรวจความเป็นไปได้ใหม่ ๆ และก้าวข้ามข้อจำกัดเดิม

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

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

 
ing03201 2024-01-09

ผมก็ติดตามบล็อก writing an os in rust อยู่เหมือนกัน แต่เริ่มมีความเคลื่อนไหวแล้วสินะ!
คิดว่าน่าจะเป็นบทความที่ดีครับ
 
GN⁺ 2024-01-09
ความคิดเห็นจาก Hacker News

  • ความเห็นจากผู้พัฒนา/ผู้เขียนโปรเจ็กต์:

    • ขอบคุณสำหรับความสนใจและการพูดคุยเกี่ยวกับโปรเจ็กต์
    • มีข้อกังวลเกี่ยวกับความอยู่รอดในระยะยาว การสนับสนุน ตลอดจนความเข้ากันได้ของคอมไพเลอร์และไบนารี
    • โปรเจ็กต์จะไม่สามารถประสบความสำเร็จได้หากไม่มีชุมชน แต่เชื่อว่าประโยชน์ที่เป็นไปได้ของโปรเจ็กต์อย่าง Motor OS จะนำไปสู่ระบบปฏิบัติการใหม่ที่ถูกใช้อย่างแพร่หลายในที่สุด
    • ชี้ให้เห็นถึงปัญหาของ Linux ภายในเครื่องเสมือน (และบางครั้งภายนอกด้วย) และมองว่านักพัฒนา Linux ไม่ได้ให้ความสำคัญกับการแก้ปัญหานี้มากพอ
    • ไม่เข้าใจข้อกังวลเกี่ยวกับความไม่เสถียรของคอมไพเลอร์และความเข้ากันได้ของไบนารี โดยระบุว่าเคอร์เนล Linux รุ่นใหม่สามารถคอมไพล์ได้ด้วย toolchain GCC หรือ LLVM ที่หลากหลาย และไบนารีเก่าก็ยังรันได้โดยไม่มีปัญหา
    • ระบุว่าพร้อมตอบคำถามเพิ่มเติม

  • คำอธิบายเกี่ยวกับแนวทาง "Rust-first":

    • "Rust-first" หมายความว่าไม่ใช่แค่ไมโครเคอร์เนลและไดรเวอร์ที่ถูกพัฒนาด้วย Rust เท่านั้น แต่โปรแกรมใน user space ก็สามารถเขียนได้ด้วย Rust เท่านั้นในตอนนี้ด้วย
    • ในทางเทคนิคสามารถ reverse engineer ABI ที่อิง Rust และ Rust toolchain ที่ให้มาเพื่อเขียนแอปสำหรับ Motor OS ด้วยภาษาอื่นอย่าง C ได้ แต่ต้องใช้แรงงานพอสมควร
    • อธิบายว่าโปรแกรม Rust มาตรฐานสามารถใช้ไลบรารีมาตรฐานของ Rust และคอมไพล์กับรันได้โดยไม่ต้องใช้ FFI

  • ข้อสงสัยว่าทำไมเคอร์เนลขนาดเล็กจึงใช้เวลา 200ms บนคอมพิวเตอร์สมัยใหม่:

    • จำเป็นต้องมีการเตรียมค่า metadata ของ memory page, เมานต์ไฟล์ซิสเต็ม, เริ่มต้นโปรเซส init ฯลฯ แต่คิดว่าทั้งหมดนี้ควรเกิดขึ้นภายในไม่กี่ไมโครวินาที
    • ตั้งคำถามว่าเป็นเพราะโฮสต์ใช้เวลาเตรียมทรัพยากรหรือไม่ เช่น มีส่วนที่ช้าใน QEMU และ KVM หรือเปล่า

  • ความเห็นที่อยากเห็นเคอร์เนลแบบ async-first ที่เขียนด้วย Rust:

    • ตั้งคำถามว่าเคอร์เนลแบบ async-first นั้นยากเป็นพิเศษหรือไม่มีคุณค่ามากพอ หรือแค่ยังไม่มีใครลองทำ
    • ระบุว่ารู้ว่าสิ่งนี้เป็นไปได้จากการติดตามซีรีส์สร้าง OS ด้วย Rust ของ Phil Oppermann แต่ดูเหมือนว่า OS ที่พัฒนาด้วย Rust ในช่วงหลังจะไม่ได้ลองแนวทางนี้

  • ความเห็นที่นึกถึงคำพูดเก่าของ Linus Torvalds เกี่ยวกับการแข่งขันกับ Linux:

    • ย้อนถึงคำตอบของ Torvalds ต่อคำถามว่าเขากลัวการแข่งขันหรือไม่ โดยเขาบอกว่าตัวเองชอบเขียน device driver และจะยังไม่กลัวการแข่งขันจนกว่าจะมีคนหนุ่มสาวที่มีแพสชันและชอบทำสิ่งนี้ปรากฏตัวขึ้น

  • ความเห็นที่สนใจโปรเจ็กต์อย่าง Motor OS และหวังว่าจะพัฒนาต่อไป:

    • แสดงความเห็นว่ามีโปรเจ็กต์แบบ Motor OS จำนวนมากที่ล้มเหลวไปแล้ว จึงยากที่จะตื่นเต้นมากนักอีกต่อไป
    • กล่าวว่าการมาแทนที่ Linux สำหรับงานเฉพาะอย่างคลาวด์นั้นเป็นเรื่องยากมาก

  • ความเห็นที่ว่า Docker, Nix OS, "serverless" มีอยู่เพราะความซับซ้อนของ Linux:

    • อธิบายว่า Docker และ NixOS มีอยู่เพราะปัญหาการจัดการแพ็กเกจใน user space ส่วน serverless มีอยู่เพราะธุรกิจต้องการจ่ายค่าคอมพิวต์ตามความต้องการ

  • ความเห็นที่ตอนแรกสงสัยในเทคโนโลยีใหม่นี้ แต่พอคิดอีกทีก็เห็นว่าประสิทธิภาพและความปลอดภัยที่ได้จากการตัดชั้นที่ไม่จำเป็นออกนั้นน่าสนใจ:

    • ระบุว่าตนมีท่าทีที่ระมัดระวังต่อเทคโนโลยีใหม่อย่างเหมาะสม และยอมรับว่าการเพิ่มขึ้นของประสิทธิภาพและความปลอดภัยนั้นน่าสนใจ

  • ความเห็นที่มองว่า Motor OS ดูเหมือนแข่งขันกับ Docker เป็นต้น:

    • ชี้ว่า Motor OS ดูเหมือนแข่งขันโดยตรงกับเทคโนโลยีอย่าง Docker มากกว่าจะไปแข่งขันกับ Linux โดยตรง
    • แสดงความเห็นว่าอยากให้ส่วน "ทำไม?" พูดถึงเหตุผลที่ควรเลือก Motor OS หรือพูดอีกอย่างคือทำไมต้องใช้ Motor OS แทน Docker เป็นต้น

  • ความเห็นที่ว่าการเริ่มต้นระบบปฏิบัติการใหม่นั้นไม่ยาก แต่การสนับสนุนระบบปฏิบัติการนั้นไปอีก 50 ปีเป็นเรื่องยากมาก:

    • เน้นว่าการเขียนระบบปฏิบัติการใหม่ไม่ใช่เรื่องยาก แต่การสนับสนุนมันในระยะยาวเป็นเรื่องที่ยากมาก
 
ahwjdekf 2024-01-10

หัวข้อ "ฟีเจอร์ที่ใช้การไม่ได้" นี่ช่างน่าทึ่งจริง ๆ โปรเจกต์ของเล่นชัด ๆ