1 คะแนน โดย GN⁺ 2025-04-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • 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
  • เครื่องมือที่ต้องใช้มีดังนี้
    • Xorriso
    • Qemu
    • NASM
    • Clang

คำสั่ง 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 ความคิดเห็น

 
GN⁺ 2025-04-26
ความคิดเห็นบน Hacker News
  • ยินดีด้วย! น่าจะภูมิใจมาก และการเลือก DOOM มาเป็น proof of concept ก็ดีมาก
    อาจเป็นคำถามมือใหม่จนหมดสนุกหน่อย แต่สงสัยว่าถ้าจะรันสิ่งนี้บนแล็ปท็อปต้องทำขั้นตอนอะไรบ้าง
    หลังจาก build แล้ว มันมีกระบวนการคล้ายกับการตั้งค่า dual boot บนพีซี Windows ไหมนะ ตลกดีที่กำลังถามคนแปลกหน้าบนอินเทอร์เน็ตว่าจะรันซอฟต์แวร์เสี่ยง ๆ บนคอมพิวเตอร์ตัวเองอย่างไร
    ถ้าอยากลองทำโปรเจกต์แบบนี้ มีตำราหรือบทความอ่านเพิ่มเติมอะไรแนะนำไหม เคยเรียนวิชาระบบปฏิบัติการและวิชาที่เกี่ยวข้องในมหาวิทยาลัย แต่ผมเรียนสายวิศวกรรมไฟฟ้า เลยเป็นแนว abstract และเน้นคอนเซปต์มาก ๆ อยากได้แหล่งข้อมูลที่เป็นรูปธรรมกว่านี้ และไม่จำเป็นต้องเป็น x64 ก็ได้

    • ไม่หมดสนุกเลย! วิธีที่ผมใช้รันบนแล็ปท็อปก็คือ ฟอร์แมต USB เป็น ISO แล้วบูตจาก USB แค่นั้นจริง ๆ
      ถ้าอยากลองเขียนเคอร์เนล แนะนำให้เริ่มจาก https://osdev.wiki ก่อน แล้วก็ควรอ่านสเปกที่เกี่ยวข้องอย่าง Intel Developer Manual รวมถึงสเปกของไดรเวอร์ที่คุณจะเขียนเองด้วย
      ผมไม่ค่อยรู้เรื่องการพัฒนาเคอร์เนลที่ไม่ใช่ x86 แต่เท่าที่รู้ คอนเซปต์ส่วนใหญ่เหมือนกัน ต่างกันแค่การ implement ทางเทคนิค ใน README ของโปรเจกต์มีลิงก์เซิร์ฟเวอร์ Discord อยู่ ในนั้นมีคนเก่ง ๆ เยอะมากและน่าจะยินดีช่วยเหลือ
    • ผมก็เขียนเคอร์เนลไว้เหมือนกัน แม้ยังไม่เสร็จ และได้ทำเอกสารทุกขั้นตอนที่ผมทำไว้ หลายคนบอกว่ามีประโยชน์: https://0xc0ffee.netlify.app/osdev
  • ก็ดีนะ แต่ทาโก้ของนายรัน DOOM ได้ไหม?
    ล้อเล่นนะ เป็นความพยายามที่น่าชื่นชมจริง ๆ ทำได้ดีมาก! สิ่งที่สงสัยคือ ตอนสร้าง TacOS คุณตั้ง DOOM เป็นเป้าหมายมาตรฐาน ไว้หรือเปล่า หรือเป้าหมายตั้งแต่แรกคือทำระบบปฏิบัติการเฉพาะทางที่รันได้แค่ DOOM
    ถามด้วยความอยากรู้ล้วน ๆ เกือบ 30 ปีก่อนผมเคยทำระบบปฏิบัติการแบบโครงกระดูกสุด ๆ ที่บูตได้เท่านั้นเพื่อเรียนรู้และความสนุก ถ้ามีระบบปฏิบัติการเฉพาะทางที่พกพาไปได้ทุกที่และแทบจะรันได้แค่ DOOM จริง ๆ มีม “อันนี้รัน DOOM ได้ไหม?” คงประชดและสนุกขึ้นไปอีกมาก
    งานเจ๋งมาก หวังว่าจะทำต่อไป

    • ไม่ได้รันได้แค่ Doom มันเป็นแค่ milestone ล่าสุดที่ผมพอร์ตมาเท่านั้น
      การทำให้ Doom รันได้เองใช้เวลาประมาณหนึ่งสัปดาห์ รวมถึงการเพิ่ม requirement ของ libc แต่ก่อนหน้านั้นมีงานวางรากฐานที่ทำไว้มากกว่านั้นเยอะ
      ผมใช้ DoomGeneric ซึ่งโดยพื้นฐานแล้วเป็น fork ของ Doom ที่ทำมาให้พอร์ตได้ง่ายมาก หวังว่าจะตอบคำถามได้นะ หรือผมอาจเข้าใจผิดก็ได้
  • การไปถึง DOOM ได้โดยตรงจากเคอร์เนลที่เขียนตั้งแต่ศูนย์นี่เหมือนใบรับรองแฮกเกอร์ระดับท็อปเลย พอเห็นมันรันบนฮาร์ดแวร์จริงคงปลื้มมาก และเท่มาก

    • การได้เห็นมันรันบนฮาร์ดแวร์จริงก็ค่อนข้างปลื้มจริง ๆ เคอร์เนลไม่ได้เข้า Doom โดยตรงเป๊ะ ๆ แต่เป็นโครงสร้างที่บูตเข้าเชลล์ก่อน แล้วจึงรัน Doom จากตรงนั้นได้
  • อาจนอกเรื่องนิดหน่อย แต่ผมก็เคยสงสัยเรื่องคล้าย ๆ กัน อยากรู้ว่ามีความพยายามทำเกมที่บูตตรงบนฮาร์ดแวร์พีซีสมัยใหม่มากแค่ไหน
    คือเป็นวิธีที่ไม่โหลดระบบปฏิบัติการเต็ม ๆ แต่เข้าเกมเลย คล้ายคอนโซลเกมรุ่นเก่า ๆ ถ้าจะทำให้เรียบง่าย Wi‑Fi, Bluetooth, GPU อาจใช้งานยากถ้าไม่มีไดรเวอร์สมัยใหม่ แต่คีย์บอร์ดกับเมาส์ดูค่อนข้างเป็นไปได้เพราะมีการเข้าถึงพื้นฐานผ่าน BIOS อะไรทำนองนั้น ศัพท์ผมอาจใช้ผิด แต่หวังว่าจะสื่อใจความได้

    • ไม่รู้ว่าถูกใช้อย่างแพร่หลายไหม แต่มันเป็นวิธีที่รู้จักกันและใช้งานได้ ผมเคยทำแบบนี้ในการทดลอง assembly x86-16 ช่วงแรก ๆ แต่สุดท้ายก็ใช้ DOS เป็นตัวรันโปรแกรม เพื่อจะได้ใช้ dosbox-staging ซึ่งเป็นอีมูเลเตอร์ที่ใช้ง่ายกว่า qemu
      ถ้าไม่อยากไปยุ่งกับ disk I/O ข้อจำกัดใหญ่คือ ไม่เกิน 512 ไบต์ เพราะโดยพื้นฐานแล้วคุณกำลังรันโปรแกรมเป็น master boot record ถ้าต้องการพื้นที่มากกว่านี้ก็ต้องอ่าน LBA จากดิสก์เข้ามาสักจำนวนหนึ่ง ซึ่งมี interrupt สำหรับเรื่องนี้ และใน osdev ก็มีข้อมูลที่ดีกว่านี้
      นอกเหนือจากนั้น ความแตกต่างระหว่างไฟล์ .com, ข้อจำกัด single segment 64KB ตามปกติ, กับโปรแกรมที่บูตได้สไตล์ MBR นั้นค่อนข้างน้อย
  • เป็นงานที่เจ๋งจริง ๆ ผมก็อยากมีฝีมือทำอะไรแบบนี้ได้ แต่กว่าจะทำได้คงต้อง อ่านสเปกจำนวนมาก ซึ่งเป็นจุดอ่อนที่สุดของผม
    อาจเป็นคำถามโง่ ๆ แต่ถ้าอยากใช้ GPU acceleration แม้ในรูปแบบเล็กมาก ๆ การทำไดรเวอร์ GPU จะยากแค่ไหน อยากรู้ว่าเอกสารที่เกี่ยวข้องทำไว้ดีหรือเปล่า

    • นั่นคงเป็นขอบเขตสุดโต่งของการพัฒนาระบบปฏิบัติการเลย และอย่างน้อยถ้าเป็นไดรเวอร์สำหรับ GPU ที่ซื้อใช้งานจริงได้ ผมก็คงทำไม่ได้เหมือนกัน
      GPU จำลองของ Qemu มีเอกสารค่อนข้างดี เลยอาจเป็นไปได้ แต่ GPU อย่าง Nvidia นั้นเอกสารแย่ และจนกระทั่งไม่นานมานี้เอกสารก็ปิดลับทั้งหมด Linux เองก็ลำบากกับเรื่องนี้ และผมก็เคยเห็นนักพัฒนาระบบปฏิบัติการงานอดิเรกบางคนสุดท้ายเอาไดรเวอร์ GPU ของ Linux มาใช้
      มีไม่กี่อย่างที่ผมติดป้ายว่าแทบเป็นไปไม่ได้ แต่การเขียน ไดรเวอร์ GPU ที่ดีจริง ๆ สำหรับ GPU ทั่วไป บอกตรง ๆ ว่าไม่คิดว่าสักวันผมจะทำได้
  • สวัสดี unmapped ผมใช้ชื่อ ThatOSDeveloper บน GitHub และ Discord และนั่นเป็นชื่อที่แสดงของผม ไม่รู้มาก่อนว่า TacOS รัน Doom ได้ เท่มากเลย
    มีบางอย่างที่สงสัยอยู่ อยากรู้ว่าเป็น Doom ต้นฉบับหรือเปล่า อยู่บนดิสก์หรือใน initramfs และใช้ Freedoom หรือ shareware Doom WAD ร่วมกับเอนจินที่ใช้

    • อย่างที่เห็นได้จากโพสต์ มันคือ doomgeneric และอย่างที่เห็นได้จากด้านบนของหน้านี้ การแก้ไขมีค่อนข้างน้อย
    • ผมใช้ DoomGeneric ซึ่งเป็น fork ของ Doom ที่พอร์ตได้ง่าย มันอยู่บน TempFS ที่โหลดจาก initrd และใช้ doom1.wad
  • เจ๋งมาก แต่ทุกวันนี้มีภาษาระดับต่ำที่ memory-safe แล้ว เลยสงสัยว่าทำไมถึงเลือกภาษาที่ไม่ปลอดภัย ทุกคนก็รู้อยู่แล้วว่าบั๊กด้านความปลอดภัยส่วนใหญ่เกี่ยวกับหน่วยความจำ
    เข้าใจว่านี่เป็นโปรเจกต์งานอดิเรก แต่ไม่เข้าใจว่าทำไมเรายังไม่เลิกใช้ ภาษาที่ไม่ปลอดภัย ทั้งที่มีทางเลือกที่ดีกว่า

    • หลัก ๆ เพราะ C เรียบง่ายกว่ามาก และในการพัฒนาเคอร์เนล ความเรียบง่ายคือทุกอย่าง
      ในโปรเจกต์อื่นผมเคยใช้ Rust แต่ในการพัฒนาเคอร์เนล ผมรู้สึกว่าอยากใช้ภาษาที่เรียบง่ายและอ่านง่ายมากกว่าภาษาที่ปลอดภัย
  • ยินดีต้อนรับสู่คลับ! ผมเคยทำเกือบเหมือนกัน และสนุกกับ ความสงบ ของการสร้างสิ่งที่ไม่มีทางกลายเป็นผลิตภัณฑ์จริงอย่างมาก
    https://jakobbr.eu/2024/08/19/writing-my-own-x86_64-operatin...

  • เป็นโปรเจกต์ที่เจ๋งจริง ๆ! อยากรู้ว่า TacOS จัดการ process isolation และ scheduling อย่างไร

    • สำหรับ virtual memory ใช้ paging เพื่อให้แต่ละ process มี address space ของตัวเอง
      มี round-robin scheduler ที่เชื่อมกับไดรเวอร์ PIT โดย PIT จะส่ง interrupt ทุก 10ms แล้ว scheduler จะทำงาน scheduler จะเลือกงานถัดไป บันทึกสถานะปัจจุบันของงานก่อนหน้า สลับไปยัง address space ใหม่ เปลี่ยน stack กู้คืน register ของงาน จากนั้นใช้คำสั่ง iretq เพื่อสลับไปยัง ring 3 user mode พร้อมกระโดดไปยัง instruction pointer
  • อยากรู้เกี่ยวกับ TacOS มากขึ้น จัดการการรันหลายโปรแกรมพร้อมกันอย่างปลอดภัยได้อย่างไร?