- Kişisel bir dinlenme projesi olarak başlayan Bunnix, x86_64 hedefli Unix benzeri bir işletim sisteminin yaklaşık bir ayda ne kadar ileri götürülebileceğini denedi ve fiili çalışma günü olarak 27 gün sürdü
- Çekirdek ağırlıklı olarak Hare ile yazıldı; ext4 desteği için lwext4 ve çekirdek video terminali için libvterm gibi C bileşenleri de kullanıldı
- Hem legacy boot hem de EFI destekleniyor ve bazı gerçek dizüstü bilgisayarlarda test edildi; ancak USB desteği olmadığı için PS/2 klavye ya da BIOS’un PS/2 emülasyonu gerekiyor
- Kullanıcı alanı dash, Doom, gzip, less, mandoc, sbase, tcc, Vim 5.7 gibi ağırlıklı olarak üçüncü taraf yazılımlardan oluşuyor; libc ise musl libc’nin Bunnix’e uyarlanmış hâli
- Bunnix çalışıyor ancak çok hatalı ve tek kullanıcılı bir sistem olarak kalıyor; uzun vadeli bakımdan çok, Helios’un yeniden işlenmesine ve çekirdek tasarımının iyileştirilmesine uzanan bir deney niteliğinde
Bunnix’in kapsamı ve çalıştırılması
- Bunnix, 21 Nisan 2024’te başlatılmış, x86_64 hedefli Unix benzeri işletim sistemi projesidir
- Fiilen çalışılmayan günler hariç toplam 27 gün harcandı
- Doğrudan çalıştırılabilecek Bunnix 0.0.0 iso sağlanıyor
- qemu’da ISO şu komutla önyüklenebilir
qemu-system-x86_64 -cdrom bunnix.iso -display sdl -serial stdio
- ISO’yu bir USB belleğe yazdırarak gerçek donanımda da önyükleme yapılabilir
- Çoğu AMD64 makinede çalışma olasılığı var
- ThinkPad X220 ve Starlabs Starbook Mk IV üzerinde test edildi
- Hem legacy boot hem de EFI destekleniyor
- Çalıştırmadaki en büyük kısıt USB desteğinin olmaması
- PS/2 klavye veya BIOS’un PS/2 emülasyonu gerekiyor
- Çoğu dizüstü klavyesi PS/2 yöntemiyle bağlıdır
- USB klavyelerde PS/2 emülasyonunun çalışıp çalışmaması ortama göre değişir
- Doom portunda tuş atamaları ve çıkış davranışıyla ilgili kısıtlar var
- WASD ile hareket
- Sağ Shift ile ateş
- Space ile kapı açma
- Oyundan çıkış çalışmadığı için oynadıktan sonra yeniden başlatmak gerekiyor
Çekirdek yapısı ve desteklenen özellikler
- Bunnix çekirdeği büyük ölçüde Hare ile yazıldı ve bazı C bileşenleri de kullanıldı
- ext4 dosya sistemi desteği için lwext4 kullanılıyor
- Çekirdek video terminali için libvterm kullanılıyor
- Desteklenen sürücüler, temel donanım ve depolama aygıtından önyükleme için gereken kapsamda yoğunlaşıyor
- PCI legacy
- AHCI blok aygıtı
- GPT ve MBR bölüm tabloları
- PS/2 klavye
- Platform seri portu
- CMOS saati
- Önyükleyicinin ayarladığı framebuffer
- ext4 ve memfs dosya sistemleri
- Unix benzeri bir sistem için gereken temel çekirdek özellikleri de içeriyor
-
Sanal dosya sistemi ve aygıtlar
- Blok aygıtları, null, zero, full sözde aygıtları,
/dev/kbd, /dev/fb0, seri ve video TTY’leri, /dev/tty denetim terminaliyle birlikte /dev sunar
- Görece tamamlanmış bir terminal emülatörü ve bir ölçüde çalışan termios desteği içerir
-
Sistem çağrıları ve kullanıcı modeli
clock_gettime, poll, openat, fork, exec, pipe, dup, dup2, ioctl dâhil yaklaşık 40 sistem çağrısını destekler- Bunnix şu anda tek kullanıcılı bir sistemdir
- Unix dosya kiplerini ve sahipliğini zorunlu kılmaz
- Birkaç gün daha çalışmayla çok kullanıcılı sisteme dönüştürülebilecek durumdadır
Önyükleyici ve kullanıcı alanı
- Bunnix iki önyükleyici içeriyor
- legacy boot için önyükleyici multiboot uyumludur ve Hare ile yazılmıştır
- EFI için önyükleyici C ile yazılmıştır
- İki önyükleyici de gerektiğinde çekirdeği ELF dosyası ve initramfs olarak yükler
- EFI önyükleyicisi initramfs sıkıştırmasını açmak için zlib içerir
- multiboot uyumlu önyükleyici sıkıştırma açma işlemini onun yerine üstlenir
- Kullanıcı alanı çoğunlukla üçüncü taraf kaynaklardan oluşur
- Colossal Cave Adventure
advent
dash /bin/sh- Doom
- gzip
- less
lok /bin/awk- lolcat
- mandoc
- sbase core utils
- tcc C derleyicisi
- Vim 5.7
- libc, musl libc’den türetildi ve Bunnix gereksinimlerine göre çeşitli değişiklikler içeriyor
- curses kütüphanesi netbsd-curses tabanlıdır
- Sistem çalışıyor ancak çok hatalı ve bazı uygulamalar aceleyle yapıldığı için çökmelere hazırlıklı olmak gerekir
Hızlı uygulamayı mümkün kılan etkenler ve zorluklar
- Bunnix kodunun bir kısmı önceki proje Helios’tan geldi
- GDT, IDT gibi genel CPU kurulumu ile ilgili bazı çekirdek kodları buna dâhil
- AHCI gibi bazı sürücüler de Bunnix sistemine uyarlanmış durumda
- Helios deneyimi olmasaydı Bunnix’i bu kadar hızlı yapmanın zor olacağı düşünülüyor
- ext4 desteği ve sanal terminal entegrasyonu özellikle zordu
- lwext4 ve libvterm adlı dış bağımlılıklar getirildi
- Dosya sistemi katmanı birkaç kez yeniden yazıldı ve hâlâ hatalar var
openat ve inode işleme dâhil Unix dosya sistemi tasarımını düzgün uygulamak için lwext4’ün içlerine daha fazla bakmak gerekti
- Hare projesi içinde Hare, assembly ve C kaynaklarını birlikte linkleme deneyimi de kazanıldı
- Genel olarak iyi çalıştı ancak ABI entegrasyon düzeneği oluşturma kısmında rahatsız edici noktalar vardı
- C header’larını Hare forward declaration modüllerine otomatik dönüştürmenin iyi olacağı ihtiyacı doğdu
- İlgili çalışmanın bir kısmı
hare-c içinde var ancak hâlâ daha fazlası gerekiyor
- Vim portunu hedeflemek terminal uygulamasının zorluğunu artırdı
- libvterm iyi bir terminal durum makinesi kütüphanesi olsa da dokümantasyonu yetersiz
- Doğru entegrasyon için çok sayıda ince ayar gerekti
- Akıcı çalışması için performans optimizasyonuna da zaman harcandı
- Zamanlayıcı, Helios tabanlı kodun önemli ölçüde atılıp yeniden yazıldığı bir alan oldu
- Helios ve Bunnix’in ikisi de tek CPU’lu sistemler
- Bunnix, Helios’tan farklı olarak çekirdek içinde bağlam değiştirmeye izin veriyor
- Öncelikli görev geçişi de çekirdek üzerinden girip çıkıyor
- Bu yapı birden çok çekirdek yığını ve farklı bir görev geçiş yöntemi gerektiriyor
- Yeterince sağlam bir zamanlayıcı olduğunda disk okuma veya
pipe(2) gibi bloklayan işleri wait queue ile basitçe uygulamak mümkün oluyor
- Sinyal uygulaması Unix uyumluluğu için gerekliydi
- Helios Unix’i hedeflemediği için sinyaller olmadan da çalışıyor
- Bunnix’te esas olarak dash portu için
SIGCHLD’nin doğru çalışmasına odaklanıldı
- Nihai sinyal uygulaması çok temel düzeyde
Helios’a uzanan tasarım dersleri
- Bunnix monolitik çekirdek, Helios ise Unix olmayan bir mikroçekirdek tasarımıdır
- Dosya sisteminde önbelleklemenin önemi doğrulandı
- Helios, dosya sistemi uygulamasını birden çok sürücüye ve ayrı süreçlere bölmüş durumda
- Yalnızca canlı nesneleri izlemek için bile dosya sistemi katmanında önbellekleme önemlidir
- Helios yeniden işlenirken dosya sistemi kodunda refaktör etme ya da yeniden yazma işi artacak
- Sürücü erişimi monolitik çekirdekte doğal olarak daha basit
- Ancak ring 0’a çok şey koyulmasından tamamen memnun değil
- Helios zamanlayıcısına monolitik tasarımın kontrol akışı unsurlarını kısmen yansıtma olasılığı var
- Bellek yönetiminde bitmap allocator beklenenden daha iyi çalıştı
- Helios’ta bitmap allocator’dan kaçınılmaya çalışılmıştı ve bellek yönetimi büyük bir rahatsızlık noktasıydı
- Bunnix, sistemin tüm genel sayfaları için basit bir bitmap allocator kullanıyor
- Endişe edilenden daha az overhead yarattı ve çok iyi çalıştı
- Bunnix’i 30 gün içinde yapmak mikroçekirdek tasarımıyla mümkün olmazdı diye düşünülüyor
- Monolitik çekirdeğin uygulanması çok daha basit
- Mikroçekirdek tasarımının avantajları da çekici; daha iyi cevap hibrit çekirdek olabilir
Proje durumu ve kalan iyileştirme adayları
- Bunnix, bundan sonra çok daha fazla zaman harcanacak bir hedeften çok, neredeyse tamamlanmış bir sanat projesi niteliğinde
- Zaman zaman birkaç gün çalışılabilir
- Topluluk iyileştirmeleri için yamalar public inbox üzerinden alınabilir
- Bundan sonraki işletim sistemi geliştirme, Bunnix’ten çıkarılan derslerle Helios’a dönüp büyük yeniden tasarımlar yapma yönünde olacak
- İyileştirme önceliği adayları şöyle
- Dosya sistemi için dizin önbelleği ve genel önbellekleme iyileştirmeleri
- ext4 hata düzeltmeleri
- procfs ve top
- Dosya mmap’i
SIGSEGV gibi ek sinyaller- Çok kullanıcılı destek
- NVMe blok aygıtı
- IDE blok aygıtı
- ATAPI ve ISO 9660 desteği
- Intel HD audio desteği
- Ağ yığını
- Temel sistemde Hare toolchain’i
- Self-hosting
1 yorum
Hacker News yorumları
Gerçekten harika. Orijinal Unix’in de Ritchie ailesi, kayınpederi ve kayınvalidesini görmek için Kaliforniya’ya tatile gittiği birkaç hafta içinde yapıldığı hikâyesini hatırlatıyor
Kaynak: Brian W. Kernighan’ın UNIX: A History and a Memoir kitabı
Şu an hafızam biraz bulanık, kontrol etmem gerekecek
“Sinyallerin baştan sona nasıl çalıştığını sonunda öğrendim ve gerçekten çirkin. Bunu Unix tasarımının en zayıf yanlarından biri olarak hep hissetmiştim; bu proje de fikrimi değiştirmedi” kısmı hakkında daha ayrıntılı kaynaklar varsa görmek isterim. HN kullanıcıları ya da yazar bir şey biliyorsa merak ederim
https://www.amazon.com/Advanced-Programming-UNIX-Environment...
Kullanıcı alanında sinyaller ve süreçler dahil Unix API’sini ele almanın sorumluluğu
Çekirdek içinde sinyalleri uygulamak istiyorsan ne önereceğimi tam bilmiyorum ama aklıma muhtemelen https://pdos.csail.mit.edu/6.828/2012/xv6.html gelir
Unix’in nasıl çalıştığını kendi kendine yeten örneklerle açık ve sistemli biçimde anlatan bir kitap okumak gerçekten ferahlatıcı. C bilmiyorsan bu bir engel olabilir ama blog yazısını okurken de aynı şey geçerli
Eşdeğer bilginin web’de bir yerlerde olduğunu sanmıyorum. Kendi blogumda da insanların hâlâ okuduğu çok Unix kırıntı bilgisi var ama aynı seviyede değil
Unix sinyallerini anlamak için blog yazıları, Google ve LLM’lerle yaklaşmanın çok verimsiz olduğu konulardan biri olduğunu düşünüyorum. İkinci elde bile “ucuz” demek zor ama içindeki bilgi değerli olduğu için fiyatı yüksek kalan bir kitap; çalışan bir programcı içinse görece ucuz
Sinyaller, tasarıma asenkron IPC’yi zorla yamamaya yönelik hantal bir girişim olduğundan yarış durumlarına açık. Sinyal işlenirken bir sinyal daha gelirse ne olacağı, süreç bir sistem çağrısının içindeyken sinyalle ne yapılacağı da belirsiz. Ertelenecek mi, kuyruğa mı alınacak, sistem çağrısından mı çıkarılacak karar vermek gerekiyor
Tüm sistem çağrıları asenkron olsaydı, birçok modern işletim sisteminin izlediği tasarım ilkelerinde olduğu gibi bu yön çözülmüş olurdu. IPC’de güvenilir kanal benzeri bir sistem olsaydı, yalnızca sinyaller değil daha incelikli asenkron süreçler arası iletişim veya prosedür çağrıları da uygulanabilirdi
SIGSTOP/SIGCONT/SIGKILL aslında sürece sinyal göndermekten çok duraklatma, sürdürme, sonlandırma gibi süreç kontrolü yapıyor
SIGHUP, SIGUSR1, SIGUSR2, SIGTTIN, SIGTTOU gibi basit asenkron mesajlar yapılandırmayı yeniden okuma gibi işlerde kötüye kullanılıyor; daemonlaştırma için nohup gibi hack tarzı dolanma yolları ekleniyor. gunicorn son ikisini dinamik ölçek büyütme/küçültmede de kullanıyor. Bu kategoride SIGWINCH gibi tuhaf derecede spesifik olanlar da var
Ayrıca SIGILL, SIGSEGV, SIGFPE gibi geçersiz komut, segmentasyon ihlali, kayan nokta istisnasını gösterenler de var. En başta asenkron bırakmanın iyi olup olmadığı belirsiz olan SIGSYS gibi şeyler de mevcut
Başka yaklaşımların da trade-off’ları var. Windows’ta event’ler, SEH, CTRL+C/CTRL+BREAK/sonlandırma işleme rutinleri, IOCP, callback’ler vb. var; Plan 9’daki notes ise string olduğu için başka süreçlere keyfi veri gönderebilmesi güzel, ama süreç kontrolünde de aynı mekanizmayı kullanmak *nix ile aynı dezavantaja sahip ve sayı yerine yalnızca string kullanıyor diye düşünüyorum
Unix sinyallerinin sorunlarını ele alıyor ve Linux’un bunları çözmek için oluşturduğu signalfd’nin neden iyi çalışmadığını da açıklıyor
https://pubs.opengroup.org/onlinepubs/009604499/functions/bs...
Sinyal işleyicisinin içindeki kodun yeniden girişli olması gerektiği de önemli. “Yeniden girişli olmayan bir fonksiyonu bir sinyal işleyicisinden çağırmak genellikle güvenli değildir”
https://man7.org/linux/man-pages/man7/signal-safety.7.html
Hare ile ilgileniyordum; bu SSS maddesini görünce bunun oldukça kendi kendini sabote eden bir politika olduğunu düşündüm: https://harelang.org/documentation/faq.html#will-hare-suppor...
Temelde geliştiricilerin istedikleri lisansı kullanmalarını, istedikleri işletim sistemini hedeflemelerini ve istedikleri kodu yazmalarını destekliyorum
Ama bu, söz konusu politikanın iyi bir fikir olduğu anlamına gelmiyor. Özgür yazılım felsefesinin en uç ya da en ilkeli grubu sayılan FSF bile Windows ve POSIX’i destekliyor. Şikâyet edip ona Woe32 diyebilirsiniz ama Stallman, özgür yazılım projelerini tescilli sistemlerde de çalışır hâle getirmenin, tescilli yazılımsız bir dünya mücadelesine daha çok yardımcı olacağını epey ikna edici biçimde savunageldi
Kütüphane kodu MPL ile lisanslandığı için Hare kullanmak tek başına sizi belirli bir lisansa bağlamıyor. Ancak masaüstlerinin %95’inden fazlasına “desteklemiyoruz, forumda sormayın, buraya gelmeyin” tavrıyla yaklaşan bir dilin ömrünün ne olacağını merak ediyorum
İronik biçimde Google’da “harelang repo” araması yapınca ilk sonuç gayriresmî macOS portu; gerçek SourceHut deposu ise ilk sayfada görünmüyor
Diller ya kartopu gibi büyür ya da yok olur. Şu anda bu yazıyı Mac’te yazıyorum ama istesem hemen şimdi bir Linux makinesi de kullanabilirim. Peki FSF’nin bile yapmadığı bir saflık testini geliştiriciye dayatan bir dili neden öğreneyim? Açık kaynak ve özgür yazılımın kayda değer bir bölümü Mac’te yazılıyor; sanılandan daha büyük bir bölümü de Windows’ta yazılıyor
Bana göre Hare’i Odin ya da Zig’den ayıran şey tam da bu saflık ve dışlayıcılık tavrı. Keyifli hack’ler ve başarı diliyorum ama ikincisi konusunda kötümserim
Öte yandan SSS’de kaş kaldırtan tek yer bu değil
“Paket yöneticisi yok ve ortak bir değer olarak kod yeniden kullanımını daha az teşvik ediyor”
“qbe, LLVM’den daha yavaş kod üretir; performans, benzer LLVM üretimli koda kıyasla çalışma zamanı performansının %25–75’i aralığındadır”
“Hare’de çok iş parçacıklılığı kullanabilir miyim? Muhtemelen hayır”
“O zaman hash tablosunu kendim mi uygulamalıyım? Evet. Hash tabloları, birçok Hare programının sıfırdan uygulamak zorunda kalacağı yaygın bir veri yapısıdır”
Şimdilik yaygın benimsenmeyi hedefleyerek tasarlanmış bir dil kesinlikle değil. Bu sorun değil; en azından bu konuda dürüstler
Fikrinizi ifade etmekte özgürsünüz, ama geliştirici zaten ilkeleri belirlemişken bu tür bir eleştirinin yapıcı olmadığını düşünüyorum
Dinlemeye değer olmak için her grubun Billboard listelerine girmesi gerekmez
Geliştiricilerin kullanmadığı işletim sistemlerini desteklemek büyük bir talep
Genel olarak çok popüler olmasa da sağlam bir nişte gelişen ve önemli rol oynayan epey dil var
Etkileyici, çok havalı ve ilham verici. “X günde etkileyici bir şey yapmak” türü örnekler, yıllar boyunca birikmiş deneyim ve yetenek gerektirir
İngilizce dizgiyi kataloğa koymam, çeşitli testleri güncellemem, yerel sistemde testleri çalıştırmam, değişiklikleri staging kümesine göndermem, beklenmedik test hatalarını düzeltmem, production’a almam, çeviri sorumlusundan birkaç dilde çeviri istemem ve dokümantasyonu da güncellemem gerekti
https://www.ticalc.org/archives/files/fileinfo/463/46387.htm...
Bunu olgun bir şeye dönüştürmek için gereken şey özel bir dehadan çok azimdir
Mastodon’da neredeyse her gün gelen güncellemeleri görmek gerçekten harikaydı. Deneyimli birinin karmaşık yazılımı parça parça nasıl bir araya getirdiğini izlemek mümkündü
https://fosstodon.org/@drewdevault/112319697309218275
Kod burada: https://git.sr.ht/~sircmpwn/bunnix/tree/master
GPLv3 lisanslı
Kullanıcı alanı çoğunlukla üçüncü taraf kaynaklardan birleştirilmiş
ISO’ya tıkladığımda 60MB indirme çıkınca ilk başta şaşırdım, ama nedeni anlaşıldı
Karşılaştırma için, Linux 0.01 71KB’lık bir indirmeydi ama yalnızca çekirdek kaynaklarını içeriyordu
Hare ilginç bir dil gibi görünüyor
Ancak bu çok çekirdekli çağda aşağıdaki sınırlamanın benimsenmesini kısıtlayacağını düşünüyorum
FAQ’a https://harelang.org/documentation/faq.html göre, Hare’de multithreading kullanılıp kullanılamayacağı sorusuna “muhtemelen hayır” yanıtı veriliyor
G/Ç işlemlerini çoklamak için event loop, CPU kaynaklarını paralel kullanmak gerektiğinde ise paylaşımlı bellekle birlikte çoklu süreç öneriliyor
Teknik olarak Hare programında thread oluşturmak mümkün. libc’ye linkleyip pthreads kullanabilir ya da clone(2) sistem çağrısını doğrudan kullanabilirsiniz. Helios gibi Hare ile uygulanmış işletim sistemleri genellikle multithreading’i uygular
Ancak upstream standart kütüphane yeniden girilebilirlik garantisi vermediğinden, kendi ayağınıza sıkmamak tamamen sizin sorumluluğunuzda
Kişisel olarak çoğu kullanım için bu yöntemi tercih ediyorum; çünkü veri yarışı olasılığını yalnızca paylaşımlı bellek bölgesiyle sınırlandırıyor. Veri yarışı açısından belleğin “unsafe block”u gibi hissettiriyor
“Linux System Call Table – Chromiumos” https://www.chromium.org/chromium-os/developer-library/refer... https://news.ycombinator.com/item?id=33395777 içeriğinden alınmış
google/syzkalleR
Fuschia / Zircon sistem çağrıları: https://fuchsia.dev/fuchsia-src/reference/syscalls
“Memory Sealing ‘Mseal’ System Call Merged for Linux 6.10”
https://news.ycombinator.com/context?id=40474551