linux kernel derlemek

linux kernel derleme, bilgisayara “senin üstündeki işletim sistemi kabuğunu ben biraz kurcalayacağım” demektir.

normal yazılım derlemek değildir bu. `npm install` patladı diye sinirlenmeye benzemez. burada derlediğin şey, işletim sisteminin kalbidir. işlemciyle, bellekle, diskle, dosya sistemiyle, sürücülerle, ağ kartıyla, scheduler’la, process yönetimiyle muhatap olan katmandır.

yani yanlış yerde kahramanlık yaparsan sistem açılmaz. sonra grub ekranına bakıp hayatı sorgularsın.

linux kernel derlemek kabaca şudur:

kernel kaynak kodunu indirirsin.
hangi özellikler açık olacak seçersin.
hangi sürücüler gömülü olacak, hangileri modül olacak karar verirsin.
derleyiciyle kernel image ve modülleri üretirsin.
sonra bunu boot edilebilir hâle getirirsin.
en sonunda da sistemin yeni kernel ile açılmasını beklersin.

buradaki “beklemek” kısmı önemlidir. çünkü kernel derleme insana sabrı öğretir.

başta çok havalı gelir.

“ben kendi kernel’imi derledim.”

güzel cümle. bilgisayar mühendisliği romantizmi var. eski okul hacker kokusu var. terminalde yeşil yazılar akıyor, fan sesi artıyor, insan kendini unix tapınağında mum yakmış gibi hissediyor.

ama gerçek şudur:

çoğu normal kullanıcı için kernel derlemek gereksizdir.

ubuntu kullanıyorsan, debian kullanıyorsan, fedora kullanıyorsan, arch kullanıyorsan zaten dağıtım sana kernel’i paketleyip veriyor. güvenlik güncellemesini, modül uyumluluğunu, initramfs işini, bootloader tarafını büyük ölçüde hallediyor.

sen niye derliyorsun?

eğer cevabın “öğrenmek için” ise güzel.
“özel donanım desteği açmak için” ise mantıklı.
“gereksiz modülleri kapatıp minimal kernel yapmak için” ise saygı duyulur.
“performans uçacak” diye ise biraz yavaş gel kardeşim.

kernel derleyince bilgisayar bir anda ferrari olmaz. yanlış config yaparsan bisiklet bile olmayabilir.

kernel derlemenin asıl olayı performans fetişi değil, kontrol ve öğrenmedir.

hangi dosya sistemi desteği var?
hangi network driver modül?
hangi güvenlik ayarları açık?
hangi debug seçenekleri kapalı?
hangi architecture için build alıyorsun?
module signing var mı?
rust desteği açık mı?
clang ile mi gcc ile mi derliyorsun?
cross compile mı yapıyorsun?

bunları düşünmeye başladığında linux’un “işletim sistemi” değil, aslında ciddi bir mühendislik kıtası olduğunu anlıyorsun.

kernel build sistemi de kendi başına ayrı bir memlekettir. adı kbuild. dışarıdan bakınca `make` diyorsun geçiyorsun ama arkada config, dependency, modül sırası, compiler flag’leri, architecture seçimi, cross compile, linker, objeler, image, modüller derken küçük çaplı üretim hattı çalışıyor.

mesela klasik akış şöyledir:

```text id="xrruz6"
make menuconfig
make -j$(nproc)
make modules_install
make install
update-grub
reboot
```

tabii bu “her dağıtımda birebir böyle yap, sonra bana dua et” reçetesi değildir. dağıtıma, bootloader’a, secure boot’a, initramfs aracına ve paketleme yöntemine göre iş değişir.

kernel derlemede en büyük bela config’tir.

çünkü config ekranında seçenek çoktur. öyle “aç kapat” gibi görünür ama bazı ayarları kapatınca sistemin nefes borusunu kesmiş olursun. disk driver’ı modül mü gömülü mü? root filesystem’i açabilecek mi? initramfs gerekli mi? ekran kartı driver’ı ne olacak? ağ kartı kalkacak mı? filesystem desteği var mı?

yanlış yerde “buna gerek yoktur ya” dersen sistem açılışta sana “asıl sana gerek yok” der.

kernel derlemenin güzel tarafı, bilgisayarı biraz daha çıplak görmektir.

normalde işletim sistemi sana tatlı bir masaüstü gösterir. kernel derlerken altındaki gerçekliği görürsün. donanım denen şeyin aslında nazlı bir hayvan olduğunu, sürücü denen şeyin medeniyetin ince çizgisi olduğunu, modül denen kavramın hayat kurtardığını anlarsın.

şimdi gelelim rust ve c++ meselesine.

linux kernel’in ana dili tarihsel olarak c’dir. biraz assembly vardır. son yıllarda rust desteği de kernel tarafında resmî olarak konuşulan ve kullanılan bir alan hâline geldi. ama bu, “linux kernel artık rust’a geçti” demek değildir. kernel hâlâ devasa ölçüde c kültürüyle yaşayan bir projedir.

c burada eski ev sahibidir.

bütün odaları bilir.
hangi boru nereden geçiyor bilir.
hangi duvarın arkasında kablo var bilir.
kodu çirkindir bazen ama sahayı bilir.

rust ise yeni gelen, güvenlik kemerini taktıran, “bunu böyle bırakırsan ileride patlar” diyen disiplinli mühendis gibidir.

rust’ın kernel tarafında cazibesi bellidir: memory safety.

kernel’de bellek hatası dediğin şey, kullanıcı uygulamasındaki “program çöktü” meselesi değildir. kernel tarafında use-after-free, null pointer, data race, buffer overflow gibi hatalar sistem güvenliği, stability ve bazen doğrudan exploit anlamına gelir.

rust burada “ben bazı hataları daha compile aşamasında yakalatırım” diye gelir.

bu önemli bir vaattir.

ama rust kernel’e sihirli değnek olarak gelmez. çünkü kernel dünyasında sadece dil bilmek yetmez. mevcut c apı’leriyle konuşmak gerekir. driver modelini anlamak gerekir. lifetime meselesi kernel objeleriyle uyuşacak mı bakmak gerekir. unsafe alanlar tamamen yok olmaz. tooling oturacak mı, maintainer kabul edecek mi, review kültürü nasıl olacak, c tarafındaki otuz yıllık alışkanlıklarla nasıl anlaşacak; bunlar gerçek sorulardır.

rust burada gelecek vadeder ama “c bitti, herkes dağılsın” demek teknoloji yorumculuğu değil, linkedin gazıdır.

c++ meselesi ise daha başka.

insan doğal olarak soruyor:

“madem c eski, neden c++ değil de rust?”

çünkü c++ kernel dünyasında biraz problemli akraba gibi görülür. güçlüdür, hızlıdır, sistem seviyesinde iş yapabilir. oyun motoru, tarayıcı motoru, trading sistemi, veritabanı, gömülü sistem tarafında canavardır. ama linux kernel’in kültürü ve teknik sınırları için c++’ın getirdiği bazı şeyler pek sevimli değildir.

exception meselesi var.
rtti meselesi var.
abi meselesi var.
name mangling var.
constructor/destructor yan etkileri var.
template karmaşası var.
standard library meselesi var.
gizli allocation ve runtime beklentileri var.

kernel geliştiricisi gizli maliyeti sevmez. “bu satır ne yapıyor?” sorusunun cevabı net olsun ister. c++ ise iyi kullanılırsa şahane, kötü kullanılırsa katedralin içine lunapark kurar.

c++’ın suçu kötü dil olması değildir. c++ çok güçlü bir dildir. ama linux kernel’in tarihsel, kültürel ve teknik gerçekliği c üzerine kuruludur. c++ ile kernel yazılmaz mı? yazılır. başka işletim sistemi veya kernel projelerinde c++ kullanılır mı? kullanılır. ama linux kernel tarafında “hadi c++’a geçelim” demek, apartmanın elektrik tesisatını bina doluyken değiştirmeye benzer.

rust’ın c++’a göre kernel tarafında daha güçlü argümanı şudur:

“ben sana modern soyutlama vereyim ama asıl satış noktam memory safety olsun.”

c++ ise şunu der:

“ben sana kontrol, performans ve devasa ekosistem vereyim ama disiplin sende olacak.”

kernel dünyasında disiplin insanda kalınca insan hata yapıyor. rust biraz bu hataları derleyiciye yakalatmaya çalışıyor. fark burada.

ama rust da insanı bedavaya kurtarmaz.

borrow checker ile kavga edersin.
unsafe yine karşına çıkar.
c tarafıyla ffi/binding gerekir.
kernel apı’leri rust’a uygun wrapper ister.
her subsystem hemen rust kabul etmez.
ekipte rust bilen maintainer sayısı c bilen kadar değildir.

yani rust daha güvenli vaat verir ama geçiş maliyeti vardır.

c++ ise kernel için “niye olmasın?” sorusunun cevabını yıllardır teknik ve kültürel bagajıyla almış gibidir. linux kernel ekosisteminde c++’ın avantajı teoride güçlü olsa da pratikte mevcut kernel kültürüne pek oturmaz.

c ise hâlâ oradadır.

çünkü kernel c ile yazılmıştır.
toolchain c’ye göre oturmuştur.
maintainer’lar c okur.
driver’lar c’dir.
patch kültürü c’dir.
macro cehennemi bile c usulüdür.
kernel’in kendi stil rehberi bile zaten ayrı bir din gibidir.

linux kernel derlemek, bu kültürle tanışmaktır biraz da.

8 karakter tab görürsün.
garip macro’lar görürsün.
`__init`, `__iomem`, `likely`, `unlikely` gibi işaretler görürsün.
normal c sandığın şeyin aslında kernel c’si olduğunu anlarsın.

sonra user space’te yazdığın c/c++/rust koduna dönüp “siz ne kadar medeniymişsiniz” dersin.

kernel derleme ne değildir?

her gün yapılacak bir eğlence değildir.
her performans sorununa çözüm değildir.
masaüstünü hızlandırmanın sihirli yolu değildir.
rastgele config kapatıp minimalizm kasma oyunu değildir.
production sunucuda “deneyelim bakalım” denecek iş değildir.
vibe coding ile “kernel optimize edelim” denecek alan hiç değildir.

kernel derleme biraz laboratuvar işidir.

öğrenirsin, denersin, bozarsın, düzeltirsin. sanal makinede yaparsan akıllıca olur. gerçek makinede yaparsan en azından eski çalışan kernel’i boot menüsünde bırakacak kadar kendini seversin.

rust vs c++ kıyasına kernel penceresinden bakarsak özet şudur:

c++, güçlü ama linux kernel için fazla bagajlıdır.
rust, daha yeni ama memory safety sebebiyle kernel için anlamlı bir deney alanıdır.
c ise hâlâ ana gövdedir; sevsen de sevmesen de ev sahibidir.

c++ “ben her şeyi yaparım” der.
rust “ben bazı saçmalıkları en baştan engellerim” der.
c “ben zaten buradaydım, önce beni anlayın” der.

kernel dünyasında en doğru cevap genelde üçünün fanatikliği değil, bağlamdır.

driver mı yazıyorsun?
mevcut subsystem ne kabul ediyor?
maintainer ne diyor?
toolchain uygun mu?
güvenlik riski nerede?
performans kritik mi?
unsafe sınırı net mi?
debug edebilecek insan var mı?

bunları sormadan “rust mı c++ mı?” tartışması yapmak, ameliyathanede tornavida markası kavgası yapmaya benzer.

linux kernel derlemek de işte bu yüzden güzel bir derstir.

sana şunu öğretir:

işletim sistemi masaüstündeki ikonlardan ibaret değildir.
performans sadece daha yeni dil seçmek değildir.
güvenlik sadece “rust yazdık” demek değildir.
kontrol sadece “c/c++ ile yazdık” demek değildir.
çekirdek seviyesinde her soyutlamanın bir faturası vardır.

özetle linux kernel derleme, bilgisayarla arandaki perdeyi biraz kaldırmaktır.

perdenin arkasında c vardır.
assembly vardır.
make vardır.
kbuild vardır.
modüller vardır.
sürücüler vardır.
bazen rust vardır.
c++ ise kapının önünde güçlü ama içeri pek alınmayan akraba gibi bekler.

ve en sonunda şunu anlarsın:

kernel derlemek havalıdır.
kernel’i anlamak daha havalıdır.
kernel’i bozup neden bozulduğunu çözmek ise gerçek eğitimdir.