- TacOS เป็น OS งานอดิเรกแบบ UNIX-like ที่ใช้เคอร์เนลของตัวเอง เขียนขึ้นใหม่ตั้งแต่ต้นด้วย C และ Assembly และสามารถรัน DOOM รวมถึงโปรแกรม user space ขนาดเล็กหลายตัวได้
- เคอร์เนลประกอบด้วย VFS, scheduler, TempFS, อุปกรณ์, context switching, การจัดการ virtual memory, การจัดสรร physical page frame และการพอร์ต Doom
- สภาพแวดล้อมการรันรองรับทั้ง ฮาร์ดแวร์จริง และ Qemu emulator โดยฮาร์ดแวร์จริงทดสอบบนแล็ปท็อปของผู้สร้าง
- การ build และรันเริ่มได้ด้วย
git clone แล้วตามด้วย make run และต้องติดตั้ง Xorriso, Qemu, NASM, Clang
- TacOS ยังไม่ได้สมบูรณ์พอสำหรับการใช้งานจริง และเป็น toy OS สำหรับงานอดิเรก ที่มีบั๊กที่ทราบอยู่หลายรายการ
ภาพรวม TacOS
- TacOS เป็น OS ที่เขียนขึ้นใหม่ตั้งแต่ต้นด้วย C และ Assembly และมีเคอร์เนลของตัวเอง
- ประกอบเป็นเคอร์เนลแบบ UNIX-like และสามารถรัน DOOM รวมถึง โปรแกรม user space ขนาดเล็กหลายตัวได้
- องค์ประกอบหลักมีดังนี้
- VFS
- scheduler
- TempFS
- อุปกรณ์
- context switching
- การจัดการ virtual memory
- การจัดสรร physical page frame
- การพอร์ต Doom
สภาพแวดล้อมการรันและข้อจำกัด
- TacOS สามารถรันได้บน ฮาร์ดแวร์จริง และ Qemu emulator
- การทดสอบบนฮาร์ดแวร์จริงดำเนินการบนแล็ปท็อปของผู้สร้าง
- โปรเจกต์นี้ไม่ใช่ OS สำเร็จรูปที่ใช้งานจริงได้ แต่เป็น toy OS สำหรับงานอดิเรก
- มีบั๊กที่ทราบอยู่หลายรายการ
เริ่มต้นอย่างรวดเร็ว
- สามารถ build และรันได้ด้วยคำสั่งต่อไปนี้
git clone https://github.com/UnmappedStack/TacOS
cd TacOS && make run
make run จะ build TacOS และรันโดยอัตโนมัติใน Qemu emulator
- เครื่องมือที่ต้องใช้มีดังนี้
คำสั่ง build
make run: build TacOS และรันใน Qemu
make qemu: รัน TacOS ที่ build ไว้แล้วใน Qemu
make disk: build อิมเมจดิสก์ทั้งหมดเป็น tacos.iso
make kernel: build เคอร์เนล TacOS ซึ่งเป็นแกนหลักของระบบ
make libc: build standard library
make userspace: build แอปพลิเคชัน user space
make initrd: สร้าง initial ramdisk สำหรับให้ระบบบูต
make lint: รันกฎ linter สำหรับเคอร์เนล
make qemu-gdb: รัน TacOS ใน Qemu พร้อมเชื่อมต่อ GDB
การดีบัก
- หากต้องการแนบ GDB ระหว่างทดสอบ TacOS ให้รัน
make qemu-gdb แล้วเชื่อมต่อกับ GDB remote target จากเทอร์มินัลอื่น
$ gdb -q
(gdb) target remote :1234
(gdb) file kernel/bin/tacos
(gdb) continue
- เมื่อต้องการดีบักเคอร์เนล ให้ระบุ
kernel/bin/tacos
- เมื่อต้องการดีบักโปรแกรม user space ให้ระบุ
initrd/usr/bin/<program>
ไลเซนส์และกติกาการมีส่วนร่วม
- TacOS ใช้ Mozilla Public License 2.0
- เปิดรับการมีส่วนร่วม แต่ก่อนส่ง pull request ต้องเปิด issue และรับการมอบหมายการเปลี่ยนแปลงก่อน
- pull request ที่มีเพียงการแก้คำผิดหรือไวยากรณ์จะไม่ถูก merge
- ข้อความ commit ต้องเป็นไปตามรูปแบบ
[component] change
- pull request ที่รวมการเปลี่ยนแปลงหลายพันบรรทัดในหลายคอมโพเนนต์ที่ไม่เกี่ยวข้องกันไว้ใน commit ขนาดใหญ่เพียงรายการเดียว จะไม่ถูกนำเข้าสู่การ review
ชุมชน
- มี Discord server สำหรับอัปเดตเกี่ยวกับ TacOS ขอความช่วยเหลือด้านโปรเจกต์ OSDev และพูดคุยกัน
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ยินดีด้วย! น่าจะภูมิใจมาก และการเลือก DOOM มาเป็น proof of concept ก็ดีมาก
อาจเป็นคำถามมือใหม่จนหมดสนุกหน่อย แต่สงสัยว่าถ้าจะรันสิ่งนี้บนแล็ปท็อปต้องทำขั้นตอนอะไรบ้าง
หลังจาก build แล้ว มันมีกระบวนการคล้ายกับการตั้งค่า dual boot บนพีซี Windows ไหมนะ ตลกดีที่กำลังถามคนแปลกหน้าบนอินเทอร์เน็ตว่าจะรันซอฟต์แวร์เสี่ยง ๆ บนคอมพิวเตอร์ตัวเองอย่างไร
ถ้าอยากลองทำโปรเจกต์แบบนี้ มีตำราหรือบทความอ่านเพิ่มเติมอะไรแนะนำไหม เคยเรียนวิชาระบบปฏิบัติการและวิชาที่เกี่ยวข้องในมหาวิทยาลัย แต่ผมเรียนสายวิศวกรรมไฟฟ้า เลยเป็นแนว abstract และเน้นคอนเซปต์มาก ๆ อยากได้แหล่งข้อมูลที่เป็นรูปธรรมกว่านี้ และไม่จำเป็นต้องเป็น x64 ก็ได้
ถ้าอยากลองเขียนเคอร์เนล แนะนำให้เริ่มจาก https://osdev.wiki ก่อน แล้วก็ควรอ่านสเปกที่เกี่ยวข้องอย่าง Intel Developer Manual รวมถึงสเปกของไดรเวอร์ที่คุณจะเขียนเองด้วย
ผมไม่ค่อยรู้เรื่องการพัฒนาเคอร์เนลที่ไม่ใช่ x86 แต่เท่าที่รู้ คอนเซปต์ส่วนใหญ่เหมือนกัน ต่างกันแค่การ implement ทางเทคนิค ใน README ของโปรเจกต์มีลิงก์เซิร์ฟเวอร์ Discord อยู่ ในนั้นมีคนเก่ง ๆ เยอะมากและน่าจะยินดีช่วยเหลือ
ก็ดีนะ แต่ทาโก้ของนายรัน DOOM ได้ไหม?
ล้อเล่นนะ เป็นความพยายามที่น่าชื่นชมจริง ๆ ทำได้ดีมาก! สิ่งที่สงสัยคือ ตอนสร้าง TacOS คุณตั้ง DOOM เป็นเป้าหมายมาตรฐาน ไว้หรือเปล่า หรือเป้าหมายตั้งแต่แรกคือทำระบบปฏิบัติการเฉพาะทางที่รันได้แค่ DOOM
ถามด้วยความอยากรู้ล้วน ๆ เกือบ 30 ปีก่อนผมเคยทำระบบปฏิบัติการแบบโครงกระดูกสุด ๆ ที่บูตได้เท่านั้นเพื่อเรียนรู้และความสนุก ถ้ามีระบบปฏิบัติการเฉพาะทางที่พกพาไปได้ทุกที่และแทบจะรันได้แค่ DOOM จริง ๆ มีม “อันนี้รัน DOOM ได้ไหม?” คงประชดและสนุกขึ้นไปอีกมาก
งานเจ๋งมาก หวังว่าจะทำต่อไป
การทำให้ Doom รันได้เองใช้เวลาประมาณหนึ่งสัปดาห์ รวมถึงการเพิ่ม requirement ของ libc แต่ก่อนหน้านั้นมีงานวางรากฐานที่ทำไว้มากกว่านั้นเยอะ
ผมใช้ DoomGeneric ซึ่งโดยพื้นฐานแล้วเป็น fork ของ Doom ที่ทำมาให้พอร์ตได้ง่ายมาก หวังว่าจะตอบคำถามได้นะ หรือผมอาจเข้าใจผิดก็ได้
การไปถึง DOOM ได้โดยตรงจากเคอร์เนลที่เขียนตั้งแต่ศูนย์นี่เหมือนใบรับรองแฮกเกอร์ระดับท็อปเลย พอเห็นมันรันบนฮาร์ดแวร์จริงคงปลื้มมาก และเท่มาก
อาจนอกเรื่องนิดหน่อย แต่ผมก็เคยสงสัยเรื่องคล้าย ๆ กัน อยากรู้ว่ามีความพยายามทำเกมที่บูตตรงบนฮาร์ดแวร์พีซีสมัยใหม่มากแค่ไหน
คือเป็นวิธีที่ไม่โหลดระบบปฏิบัติการเต็ม ๆ แต่เข้าเกมเลย คล้ายคอนโซลเกมรุ่นเก่า ๆ ถ้าจะทำให้เรียบง่าย Wi‑Fi, Bluetooth, GPU อาจใช้งานยากถ้าไม่มีไดรเวอร์สมัยใหม่ แต่คีย์บอร์ดกับเมาส์ดูค่อนข้างเป็นไปได้เพราะมีการเข้าถึงพื้นฐานผ่าน BIOS อะไรทำนองนั้น ศัพท์ผมอาจใช้ผิด แต่หวังว่าจะสื่อใจความได้
ถ้าไม่อยากไปยุ่งกับ disk I/O ข้อจำกัดใหญ่คือ ไม่เกิน 512 ไบต์ เพราะโดยพื้นฐานแล้วคุณกำลังรันโปรแกรมเป็น master boot record ถ้าต้องการพื้นที่มากกว่านี้ก็ต้องอ่าน LBA จากดิสก์เข้ามาสักจำนวนหนึ่ง ซึ่งมี interrupt สำหรับเรื่องนี้ และใน osdev ก็มีข้อมูลที่ดีกว่านี้
นอกเหนือจากนั้น ความแตกต่างระหว่างไฟล์ .com, ข้อจำกัด single segment 64KB ตามปกติ, กับโปรแกรมที่บูตได้สไตล์ MBR นั้นค่อนข้างน้อย
เป็นงานที่เจ๋งจริง ๆ ผมก็อยากมีฝีมือทำอะไรแบบนี้ได้ แต่กว่าจะทำได้คงต้อง อ่านสเปกจำนวนมาก ซึ่งเป็นจุดอ่อนที่สุดของผม
อาจเป็นคำถามโง่ ๆ แต่ถ้าอยากใช้ GPU acceleration แม้ในรูปแบบเล็กมาก ๆ การทำไดรเวอร์ GPU จะยากแค่ไหน อยากรู้ว่าเอกสารที่เกี่ยวข้องทำไว้ดีหรือเปล่า
GPU จำลองของ Qemu มีเอกสารค่อนข้างดี เลยอาจเป็นไปได้ แต่ GPU อย่าง Nvidia นั้นเอกสารแย่ และจนกระทั่งไม่นานมานี้เอกสารก็ปิดลับทั้งหมด Linux เองก็ลำบากกับเรื่องนี้ และผมก็เคยเห็นนักพัฒนาระบบปฏิบัติการงานอดิเรกบางคนสุดท้ายเอาไดรเวอร์ GPU ของ Linux มาใช้
มีไม่กี่อย่างที่ผมติดป้ายว่าแทบเป็นไปไม่ได้ แต่การเขียน ไดรเวอร์ GPU ที่ดีจริง ๆ สำหรับ GPU ทั่วไป บอกตรง ๆ ว่าไม่คิดว่าสักวันผมจะทำได้
สวัสดี unmapped ผมใช้ชื่อ ThatOSDeveloper บน GitHub และ Discord และนั่นเป็นชื่อที่แสดงของผม ไม่รู้มาก่อนว่า TacOS รัน Doom ได้ เท่มากเลย
มีบางอย่างที่สงสัยอยู่ อยากรู้ว่าเป็น Doom ต้นฉบับหรือเปล่า อยู่บนดิสก์หรือใน initramfs และใช้ Freedoom หรือ shareware Doom WAD ร่วมกับเอนจินที่ใช้
เจ๋งมาก แต่ทุกวันนี้มีภาษาระดับต่ำที่ memory-safe แล้ว เลยสงสัยว่าทำไมถึงเลือกภาษาที่ไม่ปลอดภัย ทุกคนก็รู้อยู่แล้วว่าบั๊กด้านความปลอดภัยส่วนใหญ่เกี่ยวกับหน่วยความจำ
เข้าใจว่านี่เป็นโปรเจกต์งานอดิเรก แต่ไม่เข้าใจว่าทำไมเรายังไม่เลิกใช้ ภาษาที่ไม่ปลอดภัย ทั้งที่มีทางเลือกที่ดีกว่า
ในโปรเจกต์อื่นผมเคยใช้ Rust แต่ในการพัฒนาเคอร์เนล ผมรู้สึกว่าอยากใช้ภาษาที่เรียบง่ายและอ่านง่ายมากกว่าภาษาที่ปลอดภัย
ยินดีต้อนรับสู่คลับ! ผมเคยทำเกือบเหมือนกัน และสนุกกับ ความสงบ ของการสร้างสิ่งที่ไม่มีทางกลายเป็นผลิตภัณฑ์จริงอย่างมาก
https://jakobbr.eu/2024/08/19/writing-my-own-x86_64-operatin...
เป็นโปรเจกต์ที่เจ๋งจริง ๆ! อยากรู้ว่า TacOS จัดการ process isolation และ scheduling อย่างไร
มี round-robin scheduler ที่เชื่อมกับไดรเวอร์ PIT โดย PIT จะส่ง interrupt ทุก 10ms แล้ว scheduler จะทำงาน scheduler จะเลือกงานถัดไป บันทึกสถานะปัจจุบันของงานก่อนหน้า สลับไปยัง address space ใหม่ เปลี่ยน stack กู้คืน register ของงาน จากนั้นใช้คำสั่ง iretq เพื่อสลับไปยัง ring 3 user mode พร้อมกระโดดไปยัง instruction pointer
อยากรู้เกี่ยวกับ TacOS มากขึ้น จัดการการรันหลายโปรแกรมพร้อมกันอย่างปลอดภัยได้อย่างไร?
บทนำก็ควรอ่านด้วย: https://pages.cs.wisc.edu/~remzi/OSTEP/dialogue-virtualizati...
https://wiki.osdev.org/ มีรายละเอียดของแพลตฟอร์มและแหล่งข้อมูลอื่น ๆ