HN’de paylaşıldı: DOOM çalıştıran kendi OS çekirdeğini geliştirmek

 (github.com/UnmappedStack)
1 puan yazan GN⁺ 2025-04-26 | 1 yorum | WhatsApp'ta paylaş
  • TacOS, C ve assembly ile sıfırdan yazılmış, kendi çekirdeğine dayanan UNIX-benzeri hobi amaçlı bir OS’tir; DOOM’u ve birkaç küçük kullanıcı alanı programını çalıştırabilir
  • Çekirdekte VFS, zamanlayıcı, TempFS, aygıtlar, bağlam değiştirme, sanal bellek yönetimi, fiziksel sayfa çerçevesi tahsisi ve Doom portu bulunur
  • Çalışma ortamı hem gerçek donanımı hem de Qemu emülatörünü destekler; gerçek donanım, geliştiricinin dizüstü bilgisayarında test edilmiştir
  • Derleme ve çalıştırma, git clone sonrasında make run ile başlar; Xorriso, Qemu, NASM ve Clang kurulumu gerekir
  • TacOS, gerçek kullanım için tamamlanmış bir sistem değildir; hobi amaçlı bir toy OS olarak çeşitli bilinen hatalara sahiptir

TacOS Genel Bakış

  • TacOS, C ve assembly ile yazılmış, sıfırdan geliştirilmiş bir OS’tir ve kendi çekirdeğine sahiptir
  • UNIX-benzeri bir çekirdek yapısına sahiptir ve DOOM ile birkaç küçük kullanıcı alanı programını çalıştırabilir
  • Başlıca bileşenleri şunlardır
    • VFS
    • zamanlayıcı
    • TempFS
    • aygıtlar
    • bağlam değiştirme
    • sanal bellek yönetimi
    • fiziksel sayfa çerçevesi tahsisi
    • Doom portu

Çalışma Ortamı ve Sınırlar

  • TacOS, gerçek donanımda ve Qemu emülatöründe çalışabilir
  • Gerçek donanım testleri geliştiricinin dizüstü bilgisayarında yapılmıştır
  • Proje, gerçek kullanım için hazır tamamlanmış bir OS değil, hobi amaçlı bir toy OS’tir
  • Çeşitli bilinen hatalar vardır

Hızlı Başlangıç

  • Derleme ve çalıştırma aşağıdaki komutla yapılabilir
git clone https://github.com/UnmappedStack/TacOS
cd TacOS && make run
  • make run, TacOS’u derler ve Qemu emülatöründe otomatik olarak çalıştırır
  • Gerekli araçlar şunlardır
    • Xorriso
    • Qemu
    • NASM
    • Clang

Derleme Komutları

  • make run: TacOS’u derler ve Qemu’da çalıştırır
  • make qemu: önceden derlenmiş TacOS’u Qemu’da çalıştırır
  • make disk: tam disk imajını tacos.iso olarak derler
  • make kernel: sistemin çekirdeği olan TacOS kernel’ini derler
  • make libc: standart kütüphaneyi derler
  • make userspace: kullanıcı alanı uygulamalarını derler
  • make initrd: sistemin önyükleyeceği ilk RAM diskini oluşturur
  • make lint: çekirdek için linter kurallarını çalıştırır
  • make qemu-gdb: GDB bağlı durumdayken TacOS’u Qemu’da çalıştırır

Hata Ayıklama

  • TacOS test edilirken GDB bağlamak için önce make qemu-gdb çalıştırın, ardından başka bir terminalde GDB uzak hedefe bağlanın
$ gdb -q
(gdb) target remote :1234
(gdb) file kernel/bin/tacos
(gdb) continue
  • Çekirdeği hata ayıklarken kernel/bin/tacos belirtilir
  • Kullanıcı alanı programlarını hata ayıklarken initrd/usr/bin/<program> belirtilir

Lisans ve Katkı Kuralları

  • TacOS, Mozilla Public License 2.0 kullanır
  • Katkılar açıktır, ancak pull request göndermeden önce bir issue açıp değişikliği üstlenmek gerekir
  • Yalnızca basit yazım veya dilbilgisi düzeltmeleri içeren pull request’ler birleştirilmez
  • Commit mesajları [component] change biçimini izlemelidir
  • Birbiriyle ilgisiz çok sayıda bileşende binlerce satırlık değişikliği tek bir devasa commit içinde sunan pull request’ler incelemeye alınmaz

Topluluk

  • TacOS ile ilgili güncellemeler, OSDev projelerinde yardım ve sohbet için bir Discord sunucusu vardır

İlgili okumalar

1 yorum

 
GN⁺ 2025-04-26
Hacker News yorumları

  • Tebrikler! Gurur verici olmalı, ayrıca kavram kanıtı olarak DOOM'u seçmen de güzel olmuş
    Sadece acemi sorular soruyorum diye heves kaçırıcı olabilir ama bunu bir dizüstünde çalıştırmak için nasıl bir süreç gerektiğini merak ediyorum
    Derledikten sonra Windows PC'de çift önyükleme ayarlamaya benzer bir süreç mi var diye düşünüyorum. İnternetteki yabancı birine bilgisayarımda tehlikeli yazılım çalıştırmayı sormam biraz komik geliyor
    Böyle bir proje denemek istersem önerebileceğin ders kitabı ya da okuma materyali de merak ediyorum. Üniversitede işletim sistemleri ve ilgili dersler aldım ama elektrik-elektronik mühendisliği bölümündeydim, o yüzden her şey çok soyut ve kavramsaldı. Daha somut kaynaklar iyi olurdu ve mutlaka x64 olması da gerekmiyor

    • Hiç heves kaçırıcı değil! Kendi dizüstümde çalıştırma yöntemim kelimenin tam anlamıyla USB'yi ISO ile biçimlendirmek ve USB'den önyüklemekti
      Çekirdek yazmayı denemek istiyorsan önce https://osdev.wiki sitesine bakmanı öneririm; ayrıca Intel Developer Manual gibi ilgili spesifikasyonları ve kendin yazacağın sürücüler için gereken belgeleri de okuman gerekir
      x86 dışı çekirdek geliştirme konusunda çok bilgim yok ama bildiğim kadarıyla kavramların çoğu aynı, sadece teknik uygulama farklı. Proje README'sinde Discord sunucusu bağlantısı var; orada gerçekten çok zeki insanlar bulunuyor ve isteyerek yardımcı olurlar
    • Ben de henüz bitirmedim ama bir çekirdek yazdım ve geçtiğim tüm adımları belgeledim. Birçok kişi bunu faydalı buldu: https://0xc0ffee.netlify.app/osdev

  • Güzel ama takon da DOOM çalıştırabiliyor mu?
    Şaka bir yana, gerçekten övgüyü hak eden bir emek, eline sağlık! Merak ettiğim şey şu: TacOS'u yaparken DOOM'u standart bir hedef olarak mı belirledin, yoksa baştan itibaren sadece DOOM çalıştıran özel bir işletim sistemi yapmak mı amaçtı?
    Tamamen meraktan soruyorum. Neredeyse 30 yıl önce öğrenmek ve eğlenmek için yalnızca önyükleme yapabilen aşırı iskelet bir işletim sistemi yapmıştım; ama pratikte sadece DOOM çalıştırabilen ve her yere taşınabilir özel bir işletim sistemi olsaydı, “bunda DOOM çalışır mı?” memi çok daha ironik ve komik olurdu
    Harika iş, umarım devam edersin

    • Sadece Doom çalıştırabiliyor değil; bu yalnızca son taşıdığım kilometre taşı
      Doom'un kendisini çalıştırmak, libc gereksinimlerini eklemek de dahil, yaklaşık bir hafta sürdü; ama ondan önce çok daha fazla temel çalışma yapmıştım
      DoomGeneric kullandım; bu, temelde çok taşınabilir olacak şekilde yapılmış bir Doom fork'u. Umarım sorunu yanıtlamışımdır, tabii seni yanlış anlamış da olabilirim

  • Sıfırdan yazılmış bir çekirdekte doğrudan DOOM'a kadar gelmek üst düzey bir hacker rozeti gibi bir iş. Gerçek donanımda çalıştığını görmek gerçekten büyük keyif olmalı, çok havalı

    • Gerçek donanımda çalışması gerçekten epey keyifli. Çekirdek aslında doğrudan Doom'a girmiyor; önce kabuğa önyükleniyor, sonra oradan Doom çalıştırılabiliyor

  • Biraz yan konu ama ben de buna benzer bir şeyi merak etmiştim. Modern PC donanımında doğrudan önyüklenen oyunlar yapmaya yönelik çok girişim oldu mu diye merak ediyorum
    Yani tüm işletim sistemini yüklemeden doğrudan oyuna giren bir yaklaşım; eski nesil oyun konsollarına benzer. Basit tutmak için Wi‑Fi, Bluetooth, GPU gibi şeyleri modern sürücüler olmadan kullanmak zor olabilir ama klavye ve fare için temel BIOS erişimi gibi şeyler olduğundan oldukça yapılabilir görünüyor. Terimleri yanlış kullanıyor olabilirim ama ne demek istediğim anlaşılmıştır umarım

    • Çok yaygın kullanıldı mı bilmiyorum ama bilinen bir yaklaşım ve çalışıyor. İlk x86-16 assembly deneylerimde bunu yapmıştım ama sonunda qemu'dan kullanması daha kolay bir emülatör olan dosbox-staging'i kullanabilmek için DOS'u program başlatıcısı olarak kullanmaya başladım
      Disk G/Ç işine girmek istemiyorsan büyük sınırlama 512 bayttan küçük olman gerektiği. Çünkü fiilen programı ana önyükleme kaydı olarak çalıştırıyorsun. Daha fazla alana ihtiyacın varsa diskten birkaç LBA okuman gerekir; bunun için kesmeler de var ve osdev tarafında daha iyi kaynaklar da bulunuyor
      Bunun dışında .com dosyaları, genelde 64KB tek segment sınırı, ile MBR tarzı önyüklenebilir programlar arasındaki fark oldukça küçük

  • Gerçekten havalı bir iş. Keşke benim de böyle şeyler yapacak becerim olsa ama bunu başarmak için çok fazla spesifikasyon okuman gerekmiştir diye tahmin ediyorum; bu da benim en zayıf olduğum alan
    Aptalca bir soru olabilir ama GPU hızlandırmasını çok küçük ölçekte bile kullanmak istesen GPU sürücüsü yazmanın ne kadar zor olacağını merak ediyorum. Bu konuda dokümantasyonun iyi olduğunu düşünüyor musun?

    • Bu muhtemelen işletim sistemi geliştirmenin uç noktalarından biridir ve en azından gerçekten satın alınabilen GPU'lar için sürücü yazmak söz konusuysa ben de muhtemelen yapamam
      Qemu'nun emüle ettiği GPU'nun dokümantasyonu oldukça iyi, bu yüzden mümkün olabilir; ama Nvidia GPU'lar gibi şeylerde dokümantasyon kötü ve yakın zamana kadar tamamen kapalıydı. Linux da bu yüzden zorlanıyor; hatta bazı hobi işletim sistemi geliştiricilerinin doğrudan Linux'un GPU sürücülerini aldığını bile gördüm
      Neredeyse imkânsız diye işaretlediğim çok iş yok ama yaygın bir GPU için gerçekten iyi bir GPU sürücüsü yazmak, dürüst olmak gerekirse, bir gün yapabileceğim bir şey gibi görünmüyor

  • Selam unmapped, GitHub ve Discord'da ThatOSDeveloper adını kullanıyorum, görünen adım da bu. TacOS'ta Doom çalıştırdığını bilmiyordum, oldukça havalıymış
    Birkaç şey merak ediyorum. Bunun orijinal Doom olup olmadığı, diskte mi yoksa initramfs içinde mi bulunduğu ve kullandığın motorla birlikte Freedoom mu yoksa shareware Doom WAD mi kullandığın

    • Yazıda da görebileceğin gibi doomgeneric, ayrıca bu sayfanın üst kısmında görülebileceği üzere yapılan değişiklikler oldukça az
    • Doom'un taşınabilir bir fork'u olan DoomGeneric kullanıyorum. initrd'den yüklenen TempFS üzerinde duruyor ve doom1.wad kullanıyor

  • Çok havalı ama bugünlerde düşük seviyeli ve bellek güvenli diller varken neden güvenli olmayan bir dil seçtiğini merak ediyorum. Güvenlik açıklarının çoğunun bellekle ilgili olduğunu artık herkes biliyor
    Bunun bir hobi projesi olduğunu anlıyorum ama daha iyi alternatifler varken neden güvensiz dilleri terk etmediğimizi anlamıyorum

    • Esas olarak C çok daha basit olduğu için; çekirdek geliştirmede ise basitlik her şeydir
      Başka projelerde Rust kullandım ama çekirdek geliştirmede güvenli dillerden ziyade basit ve okunması kolay bir dil kullanmayı çok daha fazla istiyormuşum gibi geliyor

  • Kulübe hoş geldin! Ben de neredeyse aynı şeyi yaptım ve asla ürüne dönüşmeyecek bir şey üretmenin verdiği huzuru gerçekten sevdim
    https://jakobbr.eu/2024/08/19/writing-my-own-x86_64-operatin...

  • Gerçekten harika bir proje! TacOS'ta süreç yalıtımı ve zamanlama nasıl ele alınıyor, merak ediyorum

    • Sanal bellekte sayfalama kullanıyorum; böylece her süreç kendi adres alanına sahip oluyor
      Round-robin zamanlayıcı, PIT sürücüsüne bağlı; PIT her 10 ms'de bir kesme üretiyor ve zamanlayıcı çalışıyor. Zamanlayıcı bir sonraki görevi seçiyor, önceki görevin mevcut durumunu kaydediyor, yeni adres alanına geçiyor, yığını değiştiriyor, görevin yazmaçlarını geri yüklüyor ve ardından iretq komutuyla ring 3 kullanıcı moduna geçip komut işaretçisine atlıyor

  • TacOS hakkında daha fazla şey öğrenmek istiyorum. Birden fazla programı aynı anda güvenli şekilde çalıştırmayı nasıl yönetiyorsun?