HN giới thiệu: Banan-OS, hệ điều hành giống Unix được viết từ đầu

 (github.com/Bananymous)
2 điểm bởi GN⁺ 2024-12-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • Banan-OS là một hệ điều hành sở thích được viết bằng C++, hiện hỗ trợ các kiến trúc x86_64 và i686
  • Phạm vi tính năng bao gồm không gian người dùng Ring3, SMP, stack mạng, nạp ELF và liên kết động, bộ nhớ copy-on-write, cho đến môi trường đồ họa cơ bản
  • Driver và chức năng hệ thống hỗ trợ đĩa NVMe/ATA, NIC dòng E1000/E1000E và RTL, đầu vào PS2/USB, hệ thống tệp Ext2/FAT, GRUB và bootloader BIOS riêng
  • TCP được đánh dấu là triển khai một phần và có lỗi, còn SSL, thiết bị virtio, một số bộ điều khiển USB, hệ thống tệp Sys/9P và bootloader UEFI riêng vẫn chưa được triển khai
  • Quá trình build xoay quanh script ./bos; sau khi tạo toolchain có thể chạy QEMU/Bochs, build kernel/image, chọn các tùy chọn kiến trúc/bootloader/UEFI/initrd

Tổng quan về Banan-OS

  • Banan-OS là một hệ điều hành sở thích được viết bằng C++
  • Kiến trúc hiện được hỗ trợ là x86_64 và i686
  • Bản demo trực tiếp được cung cấp tại bananymous.com/banan-os
  • Để chạy DOOM, cần vào môi trường GUI bằng lệnh start-gui, rồi chạy doom trong terminal GUI

Các tính năng chính đã triển khai

  • Tính năng chung

    • Không gian người dùng Ring3

      • SMP, tức đa xử lý
      • Linear framebuffer dựa trên VESA và GOP
      • Stack mạng
      • Nạp tệp thực thi ELF
      • Trình thông dịch AML một phần
      • Môi trường đồ họa cơ bản
      • Trình giả lập terminal
      • Thanh trạng thái
      • Trình khởi chạy chương trình
      • “Ứng dụng ổn” vẫn chưa được triển khai
      • Liên kết động ELF
      • Bộ nhớ copy-on-write
      • File mapping đã được triển khai
      • Anonymous mapping chưa được triển khai

Hỗ trợ driver, mạng và hệ thống tệp

  • Driver
    • Hỗ trợ đĩa NVMe và đĩa ATA IDE/SATA
    • Hỗ trợ NIC E1000, E1000E, RTL8111/8168/8211/8411
    • Bàn phím PS2 hỗ trợ mọi scancode set, chuột PS2 cũng được hỗ trợ
    • USB hỗ trợ xHCI, bàn phím, chuột, thiết bị lưu trữ dung lượng lớn và hub
    • EHCI, OHCI, UHCI, thiết bị mạng/lưu trữ virtio chưa được triển khai
  • Mạng
    • Hỗ trợ ARP, ICMP, IPv4, UDP

    • TCP được triển khai một phần và có lỗi

      • Hỗ trợ Unix domain socket
      • SSL chưa được triển khai
      • Hệ thống tệp
      • Hỗ trợ hệ thống tệp ảo, Ext2, FAT12/16/32, Dev, Ram, Proc
      • Sys và 9P chưa được triển khai
      • Bootloader
      • Hỗ trợ GRUB và bootloader BIOS riêng
      • Bootloader UEFI riêng vẫn chưa được triển khai

Cấu trúc mã nguồn

  • Mỗi thành phần và thư viện chính có thư mục con riêng như kernel, userspace, libc
  • Mỗi thư mục có thư mục include chứa toàn bộ tệp header của thành phần
  • Tất cả header được include bằng đường dẫn tuyệt đối

Build và chạy

  • Trên Ubuntu 22.04, cần các gói apt: build-essential, git, ninja-build, texinfo, bison, flex, libgmp-dev, libmpfr-dev, libmpc-dev, parted, qemu-system-x86, cpu-checker
  • Trong môi trường pacman, cần base-devel, git, wget, cmake, ninja, parted, qemu-system-x86
  • Toolchain cho hệ điều hành chỉ cần build một lần bằng ./bos toolchain
    • Vì biên dịch binutils và gcc nên có thể mất nhiều thời gian
  • Build và chạy bản thân OS bằng lệnh ./bos
    • ./bos qemu
    • ./bos qemu-nographic
    • ./bos qemu-debug
    • ./bos bochs
  • Cũng có thể chỉ build kernel hoặc disk image
    • ./bos kernel
    • ./bos image
  • Cần quyền root để tạo/chỉnh sửa disk image

Tùy chọn build và quản lý image

  • Để build cho kiến trúc khác, đặt biến môi trường BANAN_ARCH
    • Ví dụ: BANAN_ARCH=i686
  • Để đổi bootloader, đặt biến môi trường BANAN_BOOTLOADER
    • Giá trị được hỗ trợ là BANAN và GRUB
  • Để chạy bằng UEFI, cần đặt BANAN_UEFI_BOOT=1
    • Cũng cần đặt OVMF_PATH tới đúng đường dẫn OVMF; giá trị mặc định là /usr/share/ovmf/x64/OVMF.fd
  • Để tạo image initrd mà không có root filesystem vật lý, đặt BANAN_INITRD=1
    • Có thể dùng khi thử nghiệm trên phần cứng có bộ điều khiển USB không được hỗ trợ
  • Nếu disk image bị hỏng hoặc muốn tạo image mới, hãy xóa build/banan-os.img hoặc chạy ./bos image-full
  • Cũng có cung cấp script shell completion cho zsh
    • Sao chép tệp _script/shell-completion/zsh/_bos vào /usr/share/zsh/site-functions/, hoặc thêm _script/shell-completion/zsh vào fpath trong .zshrc

Cách đóng góp

  • Upstream không được host trên GitHub mà tại https://git.bananymous.com/Bananymous/banan-os
  • Vẫn có thể gửi GitHub PR, nhưng maintainer phải tải diff xuống và áp dụng thủ công
  • Cũng có thể nhận tài khoản git server riêng; trong trường hợp này cần liên hệ qua email hoặc Discord
  • Khi thêm tính năng mới, cách được ưu tiên là liên hệ maintainer trước
    • Vì đây là dự án phục vụ mục đích học tập, nếu gửi PR không hỏi trước cho tính năng mà maintainer định tự làm thì PR có thể bị đóng
    • Sửa lỗi luôn được hoan nghênh
  • Dòng đầu của commit message phải viết theo định dạng Subject: Description
    • Subject biểu thị khu vực thay đổi, như Kernel, Shell, BuildSystem
    • Dòng đầu phải nằm trong 72 ký tự
    • Phần thân nên giải thích thêm nội dung và lý do thay đổi
  • Tất cả commit phải vượt qua pre-commit hook được định nghĩa trong .pre-commit-config.yaml

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-12-06
Bình luận trên Hacker News

  • Thật sự rất ngầu và mình cũng thích cái tên này. Mình tò mò phần khó nhất mà bạn từng triển khai cho đến giờ là gì, và liệu giữa chừng có gặp trở ngại nghiêm trọng nào không

    • Không có phần nào quá sức đến mức đó, nhưng nếu phải chọn thì có lẽ là trình thông dịch AML hoặc ngăn xếp USB
      Đặc tả ACPI được viết quá lộn xộn nên trình thông dịch AML rất khó, còn USB thì vất vả vì tài liệu đặc tả quá đồ sộ và có quá nhiều tham chiếu chéo
      Không có trở ngại lớn nào, nhưng cũng có những tính năng mình bỏ dở rồi một hai tháng sau mới quay lại làm tiếp
    • Lúc đầu mình đọc thành “banyan tree”, đến khi nhìn ASCII art mới nhận ra đó là ám chỉ quả chuối

  • Quá tuyệt. Đặc biệt là việc tự triển khai driver USB từ đầu thật sự ấn tượng. Nhân tiện, mình đã thử làm hỏng nó bằng cách gõ cat doom1.wad

    • Cảm ơn. Hiện gần như không có xử lý tuần tự hóa nào cho dữ liệu ghi ra TTY, nên nếu nhét dữ liệu nhị phân tùy ý vào thì nó có thể bị vỡ :D

  • Có một câu theo thông lệ luôn phải xuất hiện trong các bài công bố kernel hệ điều hành mới, mà bài này lại thiếu mất

    • Chắc là bạn đang nói đến câu “đây là một dự án sở thích và sẽ không to lớn hay chuyên nghiệp như GNU”, đúng không?

  • Rất ngầu. Mình tò mò mỗi tuần bạn dành khoảng bao nhiêu giờ cho dự án này. Khối lượng công việc trông rất lớn
    Mình thấy hồ sơ ghi là sinh viên, không rõ có phải sinh viên đại học không, và nếu đúng vậy thì bạn có trực tiếp dùng OS này như một phần việc học không

    • Đúng, mình là sinh viên đại học. Mình đã cho giáo sư xem dự án này nên có thể “miễn” một vài môn như hệ điều hành hay đồng thời
      Ngoài chuyện đó ra thì dự án này không trực tiếp nằm trong chương trình học. Tuy vậy, nhờ nó mà mình còn kiếm được việc part-time ở mảng embedded trong trường
      Thời gian bỏ vào thay đổi rất nhiều tùy cuộc sống lúc đó thế nào. Có tháng tổng cộng chỉ 5 giờ, nhưng cũng có tuần gần như chạm mốc 40 giờ

  • Dự án tuyệt vời. Nếu đặt tên cho bản fork thì PlatanOS cũng khá ổn

    • Mình thích PlátanOS hơn, với trọng âm ở âm tiết đầu

  • Rất hay và có vẻ khối lượng công việc cực lớn. Mình tò mò thử thách nào khiến bạn nhớ nhất

    • Mình nghĩ thử thách lớn nhất là đọc những bản đặc tả dài. Trước đây mình chưa bao giờ thực sự làm việc đó, nên phải mất thời gian mới quen được

  • Quá ấn tượng. Mình tò mò quy trình phát triển của bạn diễn ra thế nào. Bạn chạy trong VM hay trên phần cứng thật, và khi ngồi xuống bắt đầu làm thì quy trình thường diễn ra ra sao
    Hẳn bạn đã học được rất nhiều khi làm việc này, nên mình cũng tò mò bạn ghi chép hay theo dõi quá trình phát triển kiểu gì. Hay chính bản thân OS này là một dạng nhật ký phát triển sống

    • Khoảng 95% việc kiểm thử được làm trong VM. Nhanh hơn và tiện hơn rất nhiều. Dù vậy mình vẫn kiểm thử định kỳ trên phần cứng thật
      Nhìn nó chạy trên bare metal thật sự lúc nào cũng rất đã, và bare metal thì không dễ dãi như VM
      Thường mình sẽ chọn một tính năng muốn thêm vào, sau đó lướt qua đặc tả liên quan và đôi khi xem các hệ điều hành hiện có xử lý nó thế nào. Sau khi dựng được mô hình trong đầu về thứ hệ thống cần, mình cứ viết code theo những gì nảy ra tại chỗ
      Mình có một thói quen rất tệ là không viết tài liệu hay ghi chú. Về cơ bản mình nhét hết vào đầu, rồi đến lúc cần lại quên mất. Với những phần phức tạp hơn thì mình có vẽ sơ đồ và ghi chú, nhưng hầu như chỉ lưu cục bộ

  • Mình tò mò rốt cuộc bạn bắt đầu viết các driver như NVMe, ATA, Realtek NIC từ đâu. Mình biết chuột và bàn phím dùng HID là chuẩn, nhưng không rõ các thiết bị khác cũng có giao thức tiêu chuẩn tương tự hay không
    Không biết có phải đó là lý do Linux trong đa số trường hợp tránh được chuyện “cài driver”, và nếu có API thiết bị chuẩn thì vì sao Windows lại hay hiện quy trình cài driver mỗi khi cắm thứ gì đó vào

    • Về cơ bản thì hầu hết các thiết bị phổ biến đều có giao thức được chuẩn hóa. Tuy vậy vẫn có những thiết bị cần nhà sản xuất cung cấp driver
      Các thiết bị mà mình viết driver đều có đặc tả được công bố miễn phí. Ví dụ NVMe có tại https://nvmexpress.org/specifications
      Mình không rõ lắm Linux hay Windows xử lý driver cụ thể ra sao. Khi biên dịch kernel Linux, bạn chỉ định driver nào được đưa vào kernel và driver nào để ở dạng module. Thường thì các driver phổ biến sẽ được build sẵn cùng kernel nên gần như không cần cài thêm về sau, chỉ cần nạp module driver là được
      Cũng có những thiết bị hoạt động với driver chung nhưng nếu có driver chuyên dụng thì sẽ dùng được nhiều tính năng hơn. Ví dụ như chỉnh LED trên chuột gaming. Có lẽ Windows cài những driver tùy chọn kiểu đó

  • Đây là một side project rất ấn tượng. Mình tò mò bạn có lời khuyên nào cho người muốn thử làm điều tương tự không, chẳng hạn nên bắt đầu từ đâu hay nên tham khảo tài liệu nào

    • Gần như cũng giống những gì người khác đã nói. Nên đọc https://wiki.osdev.org/Getting_Started, và nếu quyết định phát triển hệ điều hành thì phải nhớ rằng việc này rất tốn thời gian
    • Kiến thức thực hành thì xem OSDev Wiki, còn lý thuyết thì đọc sách về thiết kế hệ điều hành và kiến trúc máy tính
    • Với Rust thì có https://os.phil-opp.com/, còn phát triển hệ điều hành nói chung thì có https://github.com/tuhdo/os01. Và Operating Systems: Three Easy Pieces là cuốn rất đáng đọc

  • Tuyệt vời. Mình không ngờ lại có bộ tính năng như vậy. Mình tò mò liệu bạn có kế hoạch port thêm nhiều phần mềm hơn trong tương lai không

    • Có, mình định port thêm. Mình không muốn đưa mã của bên thứ ba vào OS lõi, nhưng các bản port là cách rất tốt để chạy được những thứ mình chưa tự viết
      Trên máy mình hiện vẫn có vài bản port chưa chạy được. git, binutils, gcc, make đều biên dịch được nhưng lại phát sinh những lỗi kỳ lạ. Khả năng cao là có bug ở libc hoặc phía system call của mình