HN 공개: 직접 작성한 취미 OS가 빈티지 IBM ThinkPad에서 드디어 실행됨

 (github.com/joexbayer)
4P by GN⁺ | ★ favorite | 댓글 1개
  • RetrOS-32는 i386 아키텍처를 중심으로 만든 완전 커스텀 32비트 취미 운영체제이며, 그래픽·멀티태스킹·네트워킹을 포함함
  • 커널·유틸리티·빌드 시스템은 C와 Assembly로 작성됐고, 사용자 공간 애플리케이션은 C++로 작성되며 Make와 Docker를 빌드에 사용함
  • 실제 하드웨어 테스트 대상에는 Lenovo x240, Asus Eee PC 시리즈, Dell Optiplex 780, Samsung N150 Plus, Samsung NP-NC10, IBM Thinkpad a21p가 포함됨
  • 실행 방식은 QEMU, copy.sh의 v86, 실제 하드웨어 부팅을 지원하며, 실제 기기에서는 GRUB ISO를 사용해 .iso 파일을 USB나 CD에 구워 실행함
  • 로드맵에는 부트로더, 선점형 멀티스레드 스케줄링, 파일시스템, 그래픽 창 관리자, 네트워크 스택, 사용자 공간 스레드, TCP 원격 가상 터미널 등이 구현 완료 항목으로 정리돼 있음

RetrOS-32 개요

  • RetrOS-32는 i386 아키텍처에 초점을 둔 32비트 취미 운영체제 프로젝트임
  • 프로젝트 설명은 그래픽, 멀티태스킹, 네트워킹을 갖춘 32비트 취미 운영체제라고 밝힘
  • 시작일은 2022년 5월 12일로 적혀 있음
  • 프로젝트 페이지는 Project OSHub page로 연결됨

로그인과 사용자

  • 기본 사용자는 system, admin, guest 3개임
  • admin 비밀번호는 admin이고, guest는 비밀번호가 없음
  • 현재 admin과 guest 사이의 차이는 없음
  • 사용자는 admin create <username> <password> 명령으로 만들 수 있음

구현 언어와 빌드 구성

  • 커널, 유틸리티, 빌드 시스템은 C와 Assembly로 작성됨
  • 사용자 공간 애플리케이션은 C++ 로 작성됨
  • 컴파일에는 Make를 사용함
  • 크로스플랫폼 컴파일에는 Docker를 사용함

테스트된 하드웨어

  • 테스트된 실제 하드웨어 목록은 다음과 같음
    • Lenovo x240
    • Asus Eee PC series
    • Dell Optiplex 780
    • Samsung N150 Plus
    • Samsung NP-NC10
    • IBM Thinkpad a21p

빌드와 실행 방법

  • 크로스플랫폼 환경에서는 이미지 파일 컴파일에 Docker, 에뮬레이션에 QEMU가 필요함
  • 네이티브 컴파일 의존성은 플랫폼별로 다름
    • MacOS: i386-elf-gcc, i386-elf-ld, i386-elf-g++
    • Linux / WSL Ubuntu: build-essential, gcc-multilib
    • GRUB를 부트로더로 쓰려면 grub2, xorriso, xxd도 필요함
  • Linux에서는 저장소 클론, ./debian.sh, Git 서브모듈 초기화, make compile, make img, make qemu 순서로 빌드·실행함
  • MacOS는 빌드 도구가 32비트 x86 코드에 의존하므로 현재 네이티브 컴파일이 불가하며, Docker가 가장 단순한 방법임
  • Windows는 Docker 또는 WSL을 사용함
  • 실행 방식은 세 가지임
    • copy.sh v86에서 .img 파일을 하드디스크 이미지로 업로드
    • QEMU에서 make qemu 또는 qemu-system-i386 <image name> 실행
    • 실제 하드웨어에서 .iso 파일을 USB나 CD에 굽고 GRUB ISO 사용

프로젝트 구조

  • 저장소 구조는 커널, 드라이버, 그래픽, 네트워크, 파일시스템, 라이브러리, 사용자 공간 앱, 테스트, 도구 디렉터리로 나뉨
  • boot에는 커스텀 부트로더와 multiboot.ld가 있음
  • kernel에는 주요 커널 소스와 아키텍처별 코드, 커널 스레드 코드가 있음
  • apps에는 사용자 공간 애플리케이션과 libcore.a, libgraphic.a, libnet.a가 있음
  • net에는 네트워킹 코드가 있고, fs에는 파일시스템 관련 코드가 있음
  • tools에는 빌드 도구와 스크립트가 포함됨

구현 완료 항목과 남은 작업

  • 부팅 관련 항목은 커스텀 부트로더, GRUB 호환, Stage 2 부트로더가 완료됨
  • 커널과 시스템 기능에는 다음이 포함됨
    • 멀티스레드 선점형 스케줄링
    • GDT와 TSS 기반 커널·사용자 공간 분리
    • 인터럽트 처리
    • IPC
    • 시스템 콜
    • 사용자 공간 스레드
  • 드라이버와 하드웨어 관련 기능에는 PS/2 키보드·마우스, PIT, VESA 640x480x8, RTC, Serial, E1000, PCI가 포함됨
  • 파일시스템과 저장장치 쪽에는 ATA IDE 드라이버, Ext2 유사 파일시스템, FAT16, 읽기·쓰기가 완료됨
    • FAT16은 최대 32MB 파일을 지원함
    • Atapi는 아직 미완료임
  • 메모리 기능에는 32비트 가상 메모리, 커널 kalloc/kfree, 사용자 공간 malloc/free가 포함됨
  • 그래픽 기능에는 창 관리자, GFXLib, 더블 프레임버퍼 렌더링, 마우스 이벤트, 동적 리사이즈, 전체화면, 위젯 라이브러리가 포함됨
    • Custom HTML to Widgets는 미완료임
  • 네트워크 스택에는 Ethernet, IP, ARP, UDP, Socket API, Loopback 인터페이스, DHCP, DNS, TCP, netcat 스타일 명령이 완료됨
    • Webserver, FTP, IRC, SSH, Telnet, HTTP, HTML은 미완료임
  • 애플리케이션과 도구에는 터미널, 윈도 서버, 프로세스 정보, Finder, C 컴파일러/바이트코드 인터프리터, 바이트코드 실행용 커스텀 VM, 문법 강조 편집기, 계산기, 3D 게임, 텍스트 모드 Snake 게임, TCP 원격 가상 터미널, LZ 압축 라이브러리가 포함됨
  • 제안 기능과 알려진 이슈의 전체 목록은 open issues에 있음

라이선스와 프로젝트 링크

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이런 프로젝트가 시시한 AI보다 훨씬 보기 좋음. 팔릴 물건은 아니겠지만, 기술자가 창의적으로 자기 기술을 펼치는 모습임
    10대 후반에 취미 OS 개발을 많이 공부했는데 정말 멋졌고, 지금도 가끔 작은 커널을 만들어 봄. 마지막으로 만든 건 파트너에게 메시지를 출력하는 RISC-V 작은 커널이었음

    • 팔기나 마케팅을 걱정하지 않아도 되는 게 정말 해방감 있음. 새 아이디어가 나올 때까지 바퀴를 다시 발명하면 됨
    • AI를 일괄적으로 “시시하다”고 부르는 건 이상함. 똑똑한 사용자 경험으로 포장되기 전까지는 거의 돈이 안 되는 학술적 탐구, 즉 장인적 작업에 가까웠음
    • 작은 취미용 기기가 인류 역사상 가장 말도 안 되는 기술보다 훨씬 흥미롭다는 얘기처럼 들림

  • 기본 시스템 글꼴은 더 좁은 변형이었으면 좋겠음. 그러면 시스템이 훨씬 세련돼 보일 것 같고, 글자에 가로 공간이 더 필요한 부분도 꽤 보임
    각 글자의 폭을 줄이고 글자 사이 간격도 가능한 한 좁혀야 함. 지금 쓰는 글꼴 크기와 해상도라면 1픽셀 간격이면 충분해 보임
    글꼴 시스템은 잘 모르지만 고정폭 비트맵 글꼴이라고 가정했음. 코드베이스에서 바꾸기 너무 어렵다면 신경 쓰지 않아도 됨
    나도 한동안 웹 OS 사이트를 처음부터 만들고 있고, 최근 글꼴 클래스 전체를 다시 작성해서 이 부분이 특히 눈에 들어옴

    • 지금 글꼴이 꽤 최적이 아니라는 데 동의함. 시작할 때 처음 동작시킨 초기 글꼴을 거의 그대로 쓰고 있음
      제대로 된 글꼴 렌더링도 살펴봤고 할 일 목록에 있지만, 계속 미뤄두고 있었음
    • 분위기 빡세네
      “운영체제를 만들었어요!”
      “흠, 글꼴이 별로네요”
      이게 HN의 정점 같음

  • 멋짐. 오늘 다시 시작한다면 무엇을 다르게 할지 궁금함
    저수준 부분에 어떤 언어가 적합하다고 보는지도 궁금함. C를 고수할지, 단순한 C++ 부분집합을 쓸지, 아니면 더 새로운 언어를 고려할지 같은 부분임
    자료가 워낙 많은데, 남의 코드를 베끼는 대신 프로젝트를 계속 흥미롭게 유지한 방법도 궁금함

    • 가장 크게 다르게 할 건 계획을 세우는 것임. 처음에는 기본적인 hello world OS를 만드는 목표만 있었는데, 계속 새 기능을 더하고 동시에 여러 가지를 작업하면서 아직도 갚는 중인 기술 부채가 생겼음
      UNIX 의존성도 줄이려 했을 것 같음
      언어는 기본 문법과 곧장 핵심으로 가는 스타일 때문에 C를 좋아함. 사용자 공간 애플리케이션에는 다른 언어도 고려할 수 있음
      처음부터 모든 걸 직접 작성하고 싶었고, 소프트웨어를 포팅하지 않는 것이 프로젝트의 핵심이었음. 대체로 “코드가 아니라 아이디어를 베껴라”라는 규칙을 지켰음

  • 1977년에 Commodore PET 2001을 쓰던 사람 입장에서 봐도 정말 멋짐. KolibriOS와 MenuetOSx64를 만져 보고 있었는데, 직접 OS를 만들어 보고 싶어짐. 해냈다는 게 대단함

  • 프로젝트가 정말 인상적이고 축하하고 싶음. 10대 때부터 OS 개발을 좋아했는데, 이런 성과가 실제로 구현된 걸 보니 기분 좋음
    그래픽 하위 시스템이 어떻게 초기화되는지도 조금 궁금함. 잘되길 바람

  • 나도 이런 열정 프로젝트에 시간을 낼 수 있으면 좋겠음
    실용성은 잊고, 시장 진입 전략도 잊고, 목표 시장 적합성도 잊고, 그냥 만들고 배우는 것

    • 실제로 “쓰일지”나 시장을 생각하지 않아도 되는 게 정말 상쾌함. 순전히 재미와 학습을 위한 작업임
    • 왜 시간을 낼 수 없는지 궁금함. 어릴 때부터 취미 프로젝트가 없으면 꽤 길을 잃었을 것 같음
      그중 하나가 장난감 OS였는데, 저수준 OS 개발이 실제 직업이 되면서 그 프로젝트는 멈췄음

  • 이 분야에 수십 년 있었고 OS 개발을 배우려는 중임. FASM, NASM, FASM-G는 어느 정도 알고 있음
    하지만 어셈블러 프로그램의 출력을 공부해서 OS가 바이너리 수준에서 실제로 어떻게 동작하는지 이해하고 싶음
    특정 아키텍처의 명령어 코드를 배웠는지, 장치 드라이버 프로그램은 어떻게 했는지, 직접 OS를 개발하는 단계를 정리해 줄 수 있는지 궁금함

    • 배우기 가장 좋은 곳은 osdev 포럼과 osdev 위키라고 봄. 시작하는 데 유용한 자료가 정말 많음
      튜토리얼도 몇 개 있지만, 버그가 있는 경우가 많고 사실상 그들의 OS를 다시 만드는 식이 되기 쉬움
      명령어 코드는 그렇게 깊게 파고들지는 않았고, C 컴파일러를 만들 때 찾아본 정도라 가장 흔한 기본 명령어만 알고 있음
      https://forum.osdev.org/
      https://wiki.osdev.org/Expanded_Main_Page

  • 정말 멋짐. 애플리케이션 수준보다 컴퓨터 자체를 더 많이 만지작거리던 초기 컴퓨팅 정신이 더 많이 돌아왔으면 좋겠음
    장기 취미 프로젝트로 개인용 컴퓨터를 만들어 볼까 생각해 왔음. 전체 소프트웨어 스택을 직접 만들고, 시스템에 들어가는 모든 비트의 출처를 알 수 있는 컴퓨터임
    하드웨어는 FPGA로 충분한 성능을 얻어 전부 돌릴 수 있지 않는 한 같은 수준으로 통제하기 어렵겠지만, 적어도 소프트웨어는 가능할 것 같음
    지금까지는 비현실적으로 보였는데 가능하다는 걸 보여줬음. 취미용 C 컴파일러도 구현 중인 듯함: https://github.com/joexbayer/C-Compiler

    • 사용자 공간 상단부터 드라이버까지 전부 직접 썼다는 걸 아는 건 정말 좋은 느낌임. 동시에 디버깅 지옥이기도 함
      C 컴파일러는 이 OS용으로 만들었고 OS 안에서 동작함. 프로젝트가 너무 커져서 OS 저장소에서 분리하고 싶었고, 특히 Linux에서도 동작하기 때문임

  • 이 컴파일러가 운영체제와 어떻게 상호작용하는지 더 설명해 주면 좋겠음. 특히 구조체 같은 기능을 어떻게 처리하는지, 이 영역의 현재 한계와 예정된 개선점이 궁금함

    • 컴파일러와 OS 사이에 마법 같은 상호작용은 없음. 그냥 같은 기계어(i386) 로 컴파일하고 시스템 호출에는 인터럽트를 사용함
      구조체는 멤버에 따라 크기가 정해지는 메모리 영역으로 다루고, 멤버 접근은 그 영역 안의 오프셋으로 처리함
      현재는 int와 char만 있고 switch 문도 없는 등 제한이 많음. 표준 C와 가장 큰 차이는 구조체 안의 함수 허용, 그리고 구조체 함수라면 구조체를 함수에 암시적으로 넘기는 부분임. 더 자세한 내용은 여기서 볼 수 있음:
      https://github.com/joexbayer/C-Compiler

  • 여기서 본 열정 프로젝트 중 꽤 오랜만에 가장 인상적인 것 중 하나임. 왜 직접 C 컴파일러를 쓰기로 했는지 궁금함

    • 모든 걸 직접 작성하고 싶다는 규칙이 있었고, 컴파일러를 만드는 것도 늘 내 “목표” 중 하나였음. 그래서 자연스럽게 맞아떨어졌음
답변달기