2P by GN⁺ | ★ favorite | 댓글 1개
  • Banan-OS는 C++로 작성된 취미 운영 체제이며, 현재 x86_64와 i686 아키텍처를 지원함
  • 기능 범위는 Ring3 사용자 공간, SMP, 네트워크 스택, ELF 로딩·동적 링크, copy-on-write 메모리, 기본 그래픽 환경까지 포함함
  • 드라이버와 시스템 기능은 NVMe·ATA 디스크, E1000/E1000E 및 RTL 계열 NIC, PS2·USB 입력, Ext2·FAT 파일시스템, GRUB 및 자체 BIOS 부트로더를 지원함
  • TCP는 부분 구현이며 버그가 있음으로 표시되어 있고, SSL, virtio 장치, 일부 USB 컨트롤러, Sys·9P 파일시스템, 자체 UEFI 부트로더는 아직 미구현임
  • 빌드는 ./bos 스크립트 중심으로 진행되며, 툴체인 생성 후 QEMU·Bochs 실행, 커널·이미지 빌드, 아키텍처·부트로더·UEFI·initrd 옵션 선택이 가능함

Banan-OS 개요

  • Banan-OS는 C++로 작성된 취미 운영 체제
  • 현재 지원 아키텍처는 x86_64i686
  • 라이브 데모는 bananymous.com/banan-os에서 제공됨
  • DOOM을 실행하려면 start-gui 명령으로 GUI 환경에 들어간 뒤 GUI 터미널에서 doom을 실행해야 함

구현된 주요 기능

  • 일반 기능
    • Ring3 사용자 공간

      • SMP, 즉 멀티프로세싱
      • VESA와 GOP 기반 선형 프레임버퍼
      • 네트워크 스택
      • ELF 실행 파일 로딩
      • 부분적인 AML 인터프리터
      • 기본 그래픽 환경
      • 터미널 에뮬레이터
      • 상태 표시줄
      • 프로그램 런처
      • “괜찮은 앱”은 아직 미구현
      • ELF 동적 링크
      • copy-on-write 메모리
      • 파일 매핑은 구현됨
      • 익명 매핑은 미구현

드라이버·네트워크·파일시스템 지원

  • 드라이버
    • NVMe 디스크와 ATA IDE/SATA 디스크를 지원함
    • E1000, E1000E, RTL8111/8168/8211/8411 NIC를 지원함
    • PS2 키보드는 모든 scancode set을 지원하고, PS2 마우스도 지원함
    • USB는 xHCI, 키보드, 마우스, 대용량 저장장치, 허브를 지원함
    • EHCI, OHCI, UHCI, virtio 네트워크·스토리지 장치는 미구현
  • 네트워크
    • ARP, ICMP, IPv4, UDP를 지원함
    • TCP는 부분 구현이며 버그가 있음

      • Unix domain socket을 지원함
      • SSL은 미구현
      • 파일시스템
      • 가상 파일시스템, Ext2, FAT12/16/32, Dev, Ram, Proc를 지원함
      • Sys와 9P는 미구현
      • 부트로더
      • GRUB와 자체 BIOS 부트로더를 지원함
      • 자체 UEFI 부트로더는 아직 미구현

코드 구조

  • 각 주요 컴포넌트와 라이브러리는 kernel, userspace, libc 같은 별도 하위 디렉터리를 가짐
  • 각 디렉터리에는 컴포넌트의 모든 헤더 파일을 담는 include 디렉터리가 있음
  • 모든 헤더는 절대 경로로 include됨

빌드와 실행

  • Ubuntu 22.04 기준 apt 패키지로 build-essential, git, ninja-build, texinfo, bison, flex, libgmp-dev, libmpfr-dev, libmpc-dev, parted, qemu-system-x86, cpu-checker가 필요함
  • pacman 환경에서는 base-devel, git, wget, cmake, ninja, parted, qemu-system-x86가 필요함
  • 운영 체제용 툴체인은 한 번만 ./bos toolchain으로 빌드함
    • binutils와 gcc를 컴파일하므로 시간이 오래 걸릴 수 있음
  • OS 자체 빌드와 실행은 ./bos 명령으로 수행함
    • ./bos qemu
    • ./bos qemu-nographic
    • ./bos qemu-debug
    • ./bos bochs
  • 커널이나 디스크 이미지만 빌드할 수도 있음
    • ./bos kernel
    • ./bos image
  • 디스크 이미지 생성·수정에는 root 권한이 필요함

빌드 옵션과 이미지 관리

  • 다른 아키텍처로 빌드하려면 BANAN_ARCH 환경 변수를 설정함
    • 예: BANAN_ARCH=i686
  • 부트로더를 바꾸려면 BANAN_BOOTLOADER 환경 변수를 설정함
    • 지원 값은 BANANGRUB
  • UEFI로 실행하려면 BANAN_UEFI_BOOT=1을 설정해야 함
    • OVMF_PATH도 올바른 OVMF 경로로 설정해야 하며, 기본값은 /usr/share/ovmf/x64/OVMF.fd
  • 물리 root 파일시스템 없이 initrd 이미지를 만들려면 BANAN_INITRD=1을 설정함
    • 지원되지 않는 USB 컨트롤러가 있는 하드웨어에서 테스트할 때 사용할 수 있음
  • 디스크 이미지가 손상됐거나 새 이미지를 만들고 싶으면 build/banan-os.img를 삭제하거나 ./bos image-full을 실행함
  • zsh용 shell completion 스크립트도 제공됨
    • _script/shell-completion/zsh/_bos 파일을 /usr/share/zsh/site-functions/로 복사하거나, _script/shell-completion/zsh.zshrcfpath에 추가함

기여 방식

  • 업스트림은 GitHub가 아니라 https://git.bananymous.com/Bananymous/banan-os에 호스팅됨
  • GitHub PR도 보낼 수 있지만, maintainer가 diff를 내려받아 수동 적용해야 함
  • 별도 git 서버 계정을 받을 수도 있으며, 이 경우 이메일이나 Discord로 연락해야 함
  • 새 기능 추가는 먼저 maintainer에게 연락하는 방식이 선호됨
    • 학습 목적의 프로젝트라서, maintainer가 직접 하려던 기능을 사전 문의 없이 PR로 보내면 닫힐 수 있음
    • 버그 수정은 항상 환영됨
  • 커밋 메시지는 첫 줄을 Subject: Description 형식으로 작성해야 함
    • SubjectKernel, Shell, BuildSystem처럼 변경 영역을 나타냄
    • 첫 줄은 72자 안에 들어가야 함
    • 본문은 변경 내용과 이유를 추가로 설명해야 함
  • 모든 커밋은 .pre-commit-config.yaml에 정의된 pre-commit hook을 통과해야 함

댓글과 토론

Hacker News 의견들
  • 정말 멋지고 이름도 마음에 듦. 지금까지 구현한 것 중 가장 어려웠던 부분은 무엇이었는지, 중간에 심각한 장애물도 있었는지 궁금함

    • 지나치게 어려운 부분은 없었지만, 꼽자면 AML 인터프리터USB 스택일 듯함
      ACPI 명세가 너무 엉망으로 쓰여 있어서 AML 인터프리터가 어려웠고, USB는 명세 분량이 크고 상호 참조가 많아서 힘들었음
      큰 장애물은 없었지만, 어떤 기능은 포기했다가 한두 달 뒤에 다시 돌아와서 진행하기도 함
    • 처음에는 “banyan tree”라고 읽다가 ASCII 아트를 보고서야 바나나 참조라는 걸 깨달음
  • 정말 멋짐. 특히 USB 드라이버를 처음부터 구현한 점이 대단함. 참고로 cat doom1.wad를 입력해서 망가뜨려 봤음

    • 고마움. TTY에 쓰는 데이터에 직렬화 처리가 거의 없어서, 임의의 바이너리 데이터를 먹이면 깨질 수 있음 :D
  • 새 운영체제 커널 발표에는 관례적으로 들어가야 하는 문장이 있는데, 이 발표에는 그 문장이 빠져 있음

    • 분명 “이건 취미 프로젝트이고 GNU처럼 크고 전문적이진 않을 것이다”라는 문장을 말하는 거겠지?
  • 멋짐. 주당 몇 시간 정도 이 프로젝트에 쓰는지 궁금함. 들어간 작업량이 상당해 보임
    프로필에 학생이라고 되어 있는데 대학생이라는 뜻인지, 그렇다면 학업의 일부로도 이 OS를 직접 다뤘는지 궁금함

    • 대학생이 맞음. 프로젝트를 교수에게 보여줘서 운영체제동시성 같은 일부 과목은 “건너뛸” 수 있었음
      그 외에는 이 프로젝트가 학업에 직접 포함되어 있지는 않음. 다만 이 프로젝트 덕분에 대학의 임베디드 쪽에서 파트타임 일도 얻게 됨
      투입 시간은 그때그때 삶에서 무슨 일이 있느냐에 따라 정말 달라짐. 어떤 달은 총 5시간만 넣었고, 어떤 주는 거의 40시간 가까이 하기도 함
  • 멋진 프로젝트임. 포크 이름으로는 PlatanOS도 괜찮을 듯

    • 첫 음절에 강세를 둔 PlátanOS가 좋겠음
  • 아주 좋고 작업량이 많아 보임. 특히 기억에 남는 도전 과제는 무엇이었는지 궁금함

    • 가장 큰 도전은 큰 명세서를 읽는 일이었던 것 같음. 전에는 그런 일을 제대로 해본 적이 없어서 익숙해지는 데 시간이 걸렸음
  • 굉장함. 개발은 어떤 식으로 하는지 궁금함. VM에서 돌리는지, 실제 하드웨어에서 돌리는지, 앉아서 작업을 시작하면 과정이 어떻게 흘러가는지 알고 싶음
    이걸 하면서 많이 배웠을 텐데, 노트나 개발 추적은 어떻게 하는지도 궁금함. 아니면 OS 자체가 살아 있는 개발 일지 같은 건지도 궁금함

    • 테스트의 95% 정도는 VM에서 함. 훨씬 빠르고 훨씬 편함. 그래도 실제 하드웨어에서도 정기적으로 테스트함
      실제 베어메탈에서 돌아가는 걸 보는 건 언제나 멋지고, 베어메탈은 VM만큼 관대하지 않음
      보통 추가하고 싶은 기능을 정한 다음 관련 명세를 대략 훑고, 기존 운영체제들이 어떻게 처리하는지도 가끔 봄. 시스템이 무엇을 필요로 하는지 머릿속 모델을 만든 뒤, 그 자리에서 떠오르는 대로 코드를 씀
      문서나 노트를 안 쓰는 정말 나쁜 습관이 있음. 기본적으로 전부 머릿속에 넣어두고, 나중에 그 정보가 필요할 때 잊어버림. 더 복잡한 것은 다이어그램을 그리고 노트를 쓰기도 하지만, 거의 로컬에만 보관함
  • NVMe, ATA, Realtek NIC 같은 드라이버는 대체 어디서부터 작성하기 시작하는지 궁금함. 마우스와 키보드는 표준인 HID를 쓴다는 건 알지만, 다른 장치들도 비슷한 표준 프로토콜이 있는지 궁금함
    Linux가 대부분의 경우 “드라이버 설치”를 피할 수 있는 이유가 이것인지, 표준 장치 API가 있다면 Windows는 왜 뭔가를 꽂을 때마다 드라이버 설치 절차를 거치는지도 궁금함

    • 기본적으로 흔히 쓰이는 장치는 거의 다 프로토콜이 표준화되어 있음. 다만 제조사가 드라이버를 제공해야 하는 장치도 있음
      내가 드라이버를 작성한 장치들은 모두 명세가 무료로 공개되어 있었음. 예를 들어 NVMe는 https://nvmexpress.org/specifications에 있음
      Linux나 Windows가 드라이버를 어떻게 처리하는지는 잘 모름. Linux 커널을 컴파일할 때 어떤 드라이버를 커널에 포함할지, 어떤 것을 모듈로 둘지 지정함. 보통 흔한 드라이버는 커널과 함께 빌드되므로 나중에 설치할 필요가 거의 없고, 드라이버 모듈만 로드하면 됨
      또 범용 드라이버로 동작하지만 전용 드라이버가 있으면 더 많은 기능을 쓰는 장치도 있음. 예를 들어 게이밍 마우스의 LED 설정 같은 것임. Windows는 아마 이런 선택적 드라이버를 설치하는 것 같음
  • 아주 멋진 사이드 프로젝트임. 비슷한 걸 시도하려는 사람에게 어디서 시작할지, 참고 자료는 무엇이 좋을지 같은 팁이 있는지 궁금함

    • 다른 사람들이 말한 것과 거의 같음. https://wiki.osdev.org/Getting_Started를 읽어보는 게 좋고, 운영체제를 개발하기로 하면 시간이 많이 걸린다는 점을 염두에 둬야 함
    • 실용 지식은 OSDev Wiki, 이론은 운영체제 설계와 컴퓨터 구조 책을 보면 됨
    • Rust로는 https://os.phil-opp.com/가 있고, 일반적인 운영체제 개발에는 https://github.com/tuhdo/os01가 있음. 그리고 Operating Systems: Three Easy Pieces는 꼭 읽는 게 좋음
  • 훌륭함. 이런 기능 구성을 예상하지 못했음. 앞으로 더 많은 소프트웨어를 이식할 계획이 있는지 궁금함

    • 더 이식할 계획이 있음. 기본 OS에는 서드파티 코드를 넣지 않고 싶지만, 포트는 아직 직접 작성하지 않은 것들을 실행할 수 있게 해주는 아주 좋은 방법임
      로컬에는 아직 동작하지 않는 포트가 몇 개 있음. git, binutils, gcc, make는 모두 컴파일되지만 이상한 오류를 내고 있음. 아마 내 libc나 시스템 호출 쪽 버그일 가능성이 큼