HN chia sẻ: Tự phát triển kernel OS của riêng tôi để chạy DOOM

 (github.com/UnmappedStack)
1 điểm bởi GN⁺ 2025-04-26 | 1 bình luận | Chia sẻ qua WhatsApp
  • TacOS là một hệ điều hành kiểu UNIX mang tính hobby, dựa trên kernel tự viết từ đầu bằng C và assembly, có thể chạy DOOM cùng nhiều chương trình userspace nhỏ
  • Kernel bao gồm VFS, scheduler, TempFS, thiết bị, context switching, quản lý bộ nhớ ảo, cấp phát khung trang vật lý và bản port Doom
  • Môi trường chạy hỗ trợ cả phần cứng thật lẫn trình giả lập Qemu, trong đó phần cứng thật đã được tác giả thử nghiệm trên laptop của mình
  • Việc build và chạy bắt đầu bằng git clone rồi make run, và cần cài Xorriso, Qemu, NASM, Clang
  • TacOS chưa phải là một OS hoàn chỉnh để sử dụng thực tế mà là một toy OS mang tính hobby, có nhiều lỗi đã biết

Tổng quan về TacOS

  • TacOS là một OS được viết from-scratch bằng C và assembly, có kernel riêng
  • Hệ thống được tổ chức như một kernel kiểu UNIX và có thể chạy DOOM cùng nhiều chương trình userspace nhỏ
  • Các thành phần chính gồm:
    • VFS
    • scheduler
    • TempFS
    • thiết bị
    • context switching
    • quản lý bộ nhớ ảo
    • cấp phát khung trang vật lý
    • bản port Doom

Môi trường chạy và giới hạn

  • TacOS có thể chạy trên phần cứng thật và trong trình giả lập Qemu
  • Việc thử nghiệm trên phần cứng thật được thực hiện trên laptop của tác giả
  • Dự án không phải là một OS hoàn chỉnh sẵn sàng cho sử dụng thực tế mà là một toy OS mang tính hobby
  • Có nhiều lỗi đã biết

Bắt đầu nhanh

  • Có thể build và chạy bằng các lệnh sau
git clone https://github.com/UnmappedStack/TacOS
cd TacOS && make run
  • make run sẽ build TacOS và tự động chạy trong trình giả lập Qemu
  • Các công cụ cần thiết gồm:
    • Xorriso
    • Qemu
    • NASM
    • Clang

Lệnh build

  • make run: build TacOS và chạy trong Qemu
  • make qemu: chạy TacOS đã được build trong Qemu
  • make disk: build toàn bộ ảnh đĩa thành tacos.iso
  • make kernel: build kernel TacOS, thành phần lõi của hệ thống
  • make libc: build thư viện chuẩn
  • make userspace: build các ứng dụng userspace
  • make initrd: tạo ramdisk ban đầu để hệ thống khởi động
  • make lint: chạy các quy tắc lint cho kernel
  • make qemu-gdb: chạy TacOS trong Qemu với GDB đã được gắn kết

Gỡ lỗi

  • Để gắn GDB khi thử nghiệm TacOS, hãy chạy make qemu-gdb rồi ở một terminal khác kết nối tới remote target của GDB
$ gdb -q
(gdb) target remote :1234
(gdb) file kernel/bin/tacos
(gdb) continue
  • Khi gỡ lỗi kernel, hãy chỉ định kernel/bin/tacos
  • Khi gỡ lỗi chương trình userspace, hãy chỉ định initrd/usr/bin/<program>

Giấy phép và quy tắc đóng góp

  • TacOS sử dụng Mozilla Public License 2.0
  • Việc đóng góp được mở, nhưng trước khi gửi pull request thì phải mở issue và được phân công thay đổi
  • Pull request chỉ chứa sửa lỗi chính tả hoặc ngữ pháp đơn giản sẽ không được merge
  • Commit message phải theo định dạng [component] change
  • Pull request gộp hàng nghìn dòng thay đổi ở nhiều component không liên quan vào một commit khổng lồ sẽ không được review

Cộng đồng

  • Có máy chủ Discord để cập nhật về TacOS, hỗ trợ cho các dự án OSDev và trao đổi

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-04-26
Ý kiến trên Hacker News

  • Chúc mừng! Hẳn là bạn rất tự hào, và chọn DOOM làm bản chứng minh ý tưởng cũng hay nữa.
    Có thể hơi mất hứng vì toàn câu hỏi của người mới, nhưng tôi tò mò là nếu muốn chạy cái này trên laptop thì cần những bước nào.
    Sau khi build xong, có phải quy trình giống như thiết lập dual boot trên PC Windows không. Hơi buồn cười là tôi đang hỏi một người lạ trên Internet cách chạy phần mềm nguy hiểm trên máy tính của mình.
    Nếu muốn thử làm một dự án như thế này, bạn có gợi ý giáo trình hay tài liệu đọc nào không? Tôi có học hệ điều hành và các môn liên quan ở đại học, nhưng vì học ngành điện-điện tử nên tất cả đều rất trừu tượng và thiên về khái niệm. Tôi muốn có tài liệu cụ thể hơn, và không nhất thiết phải là x64.

    • Không mất hứng chút nào! Cách tôi chạy trên laptop của mình đúng nghĩa chỉ là format USB bằng ISO rồi boot từ USB.
      Nếu muốn thử viết kernel, trước hết tôi khuyên nên xem https://osdev.wiki, và cũng cần đọc các đặc tả liên quan như Intel Developer Manual cùng các đặc tả của driver mà bạn sẽ tự viết.
      Tôi không rành phát triển kernel ngoài x86, nhưng theo những gì tôi biết thì phần lớn khái niệm là giống nhau, chỉ khác cách triển khai kỹ thuật. Trong README của dự án có link tới server Discord, ở đó có rất nhiều người cực kỳ giỏi và họ sẽ sẵn lòng giúp.
    • Tôi cũng đã viết một kernel, dù chưa hoàn thiện, và đã ghi lại toàn bộ các bước mình làm. Nhiều người nói nó hữu ích: https://0xc0ffee.netlify.app/osdev

  • Hay đấy, nhưng taco của bạn có chạy được DOOM không?
    Đùa thôi, thật sự là một nỗ lực đáng khen, làm tốt lắm! Điều tôi tò mò là khi tạo TacOS, bạn xem DOOM là mục tiêu chuẩn nào đó, hay ngay từ đầu mục tiêu là tạo một hệ điều hành chuyên dụng chỉ để chạy DOOM?
    Tôi hỏi hoàn toàn vì tò mò. Gần 30 năm trước, tôi từng tạo một hệ điều hành cực kỳ sơ sài chỉ boot được để học và cho vui; nếu có một hệ điều hành chuyên dụng về cơ bản chỉ chạy được DOOM và có thể port đi khắp nơi, thì meme “cái này chạy được DOOM không?” sẽ còn mỉa mai và thú vị hơn nhiều.
    Công việc rất tuyệt, mong bạn tiếp tục.

    • Không phải nó chỉ chạy được Doom; đó chỉ là milestone mới nhất mà tôi port thôi.
      Riêng việc chạy Doom, bao gồm cả việc thêm các yêu cầu libc, mất khoảng một tuần; còn phần nền tảng đã làm trước đó thì nhiều hơn rất nhiều.
      Tôi dùng DoomGeneric, về cơ bản là một fork của Doom được làm để rất dễ port. Hy vọng câu này trả lời được câu hỏi của bạn, cũng có thể tôi đã hiểu sai.

  • Đi từ kernel tự viết từ đầu đến chạy được DOOM trên đó đúng là kiểu chứng nhận hacker hạng cao nhất. Thấy nó chạy trên phần cứng thật chắc hẳn rất vui, và quá ngầu.

    • Chạy được trên phần cứng thật thì khá vui. Kernel không đi thẳng vào Doom hẳn; cấu trúc là boot vào shell rồi từ đó có thể chạy Doom.

  • Hơi lạc đề một chút, nhưng tôi cũng từng thắc mắc chuyện tương tự. Không biết đã có nhiều nỗ lực làm game boot trực tiếp trên phần cứng PC hiện đại chưa.
    Tức là không nạp cả hệ điều hành mà vào thẳng game, giống các máy console thế hệ cũ. Để giữ đơn giản, những thứ như Wi-Fi, Bluetooth, GPU chắc khó tận dụng nếu không có driver hiện đại, nhưng bàn phím và chuột thì có các cơ chế kiểu truy cập BIOS cơ bản nên có vẻ khá khả thi. Có thể thuật ngữ tôi dùng không đúng, nhưng hy vọng ý chính được truyền đạt.

    • Tôi không biết nó có được dùng nhiều không, nhưng đây là cách đã được biết đến và hoạt động được. Trong các thử nghiệm assembly x86-16 ban đầu, tôi từng làm kiểu này, nhưng rốt cuộc lại dùng DOS làm trình chạy chương trình để có thể dùng dosbox-staging, một emulator dễ dùng hơn qemu.
      Nếu không muốn đụng tới I/O đĩa, giới hạn lớn là tối đa 512 byte. Vì về cơ bản bạn đang chạy chương trình như master boot record. Nếu cần thêm không gian, bạn phải đọc vài LBA từ đĩa; cũng có interrupt cho việc này, và osdev có tài liệu tốt hơn.
      Ngoài ra thì khác biệt giữa file .com, thường bị giới hạn ở một segment 64KB duy nhất, và chương trình có thể boot kiểu MBR là khá nhỏ.

  • Công việc thật sự rất tuyệt. Tôi cũng ước mình có kỹ năng làm được thứ như vậy, nhưng để làm được chắc phải đọc rất nhiều đặc tả, mà đó lại là điểm yếu nhất của tôi.
    Có thể là câu hỏi ngớ ngẩn, nhưng nếu muốn dùng tăng tốc GPU dù chỉ ở dạng rất nhỏ, thì việc tạo GPU driver khó đến mức nào? Bạn có nghĩ tài liệu liên quan được viết tốt không?

    • Việc đó có lẽ là vùng cực hạn của phát triển hệ điều hành, và ít nhất nếu là driver cho GPU có thể mua ngoài đời thật thì khả năng cao tôi cũng không làm nổi.
      GPU giả lập của Qemu có tài liệu khá ổn nên có thể làm được, nhưng những thứ như GPU Nvidia thì tài liệu kém, và cho đến gần đây tài liệu còn hoàn toàn đóng. Linux cũng khổ vì vấn đề này, và tôi từng thấy vài nhà phát triển hệ điều hành hobby cuối cùng lấy GPU driver của Linux về dùng.
      Không có nhiều việc tôi đánh dấu là gần như bất khả thi, nhưng thành thật mà nói, tôi không nghĩ một ngày nào đó mình có thể viết một GPU driver thật sự tử tế cho GPU phổ biến.

  • Chào unmapped, tôi dùng tên ThatOSDeveloper trên GitHub và Discord, đó là tên hiển thị của tôi. Tôi không biết TacOS đã chạy được Doom, khá ngầu đấy.
    Tôi có vài điều muốn hỏi. Đó có phải Doom gốc không, nó nằm trên đĩa hay trong initramfs, và bạn dùng Freedoom hay shareware Doom WAD cùng với engine đang dùng?

    • Như có thể thấy trong bài, đó là doomgeneric, và như có thể thấy ở đầu trang này, phần chỉnh sửa khá ít.
    • Tôi dùng DoomGeneric, một fork dễ port của Doom. Nó nằm trên TempFS được load từ initrd, và dùng doom1.wad.

  • Rất ngầu, nhưng ngày nay đã có các ngôn ngữ low-level mà vẫn memory-safe, vậy tại sao lại chọn một ngôn ngữ không an toàn? Tất cả chúng ta đều biết phần lớn lỗi bảo mật liên quan đến bộ nhớ.
    Tôi hiểu đây là dự án hobby, nhưng không hiểu vì sao không loại bỏ ngôn ngữ không an toàn khi đã có lựa chọn thay thế tốt hơn.

    • Chủ yếu vì C đơn giản hơn nhiều, và trong phát triển kernel thì sự đơn giản là tất cả.
      Tôi đã dùng Rust trong các dự án khác, nhưng với phát triển kernel, tôi cảm thấy mình muốn dùng một ngôn ngữ đơn giản và dễ đọc hơn là một ngôn ngữ an toàn.

  • Chào mừng đến với câu lạc bộ! Tôi từng làm gần như điều tương tự, và thật sự rất thích sự bình yên khi tạo ra một thứ chắc chắn sẽ không bao giờ trở thành sản phẩm.
    https://jakobbr.eu/2024/08/19/writing-my-own-x86_64-operatin...

  • Dự án thật sự rất tuyệt! Tôi tò mò TacOS xử lý cách ly tiến trình và scheduling như thế nào.

    • Với bộ nhớ ảo, tôi dùng paging để mỗi tiến trình có không gian địa chỉ riêng.
      Có một round-robin scheduler nối với PIT driver; cứ mỗi 10ms, PIT phát interrupt và scheduler chạy. Scheduler chọn tác vụ tiếp theo, lưu trạng thái hiện tại của tác vụ trước đó, chuyển sang không gian địa chỉ mới, đổi stack, khôi phục các thanh ghi của tác vụ, rồi dùng lệnh iretq để chuyển sang user mode ring 3 và nhảy tới instruction pointer.

  • Tôi muốn biết thêm về TacOS. Bạn quản lý việc chạy an toàn nhiều chương trình cùng lúc như thế nào?