Hobi amacli bir cekirdek gelistirmek yapabilecegin en mantikli seylerden biri olabilir kendini yazilim konusunda gelistirmek icin, oncelikle seni tebrik ederim. Fakat zor bir yola bas koydugunu da bilmelisin cunku cidden zor ve bilgisayar tarafinda teorik bir arkaplan isteyen bir is kernel gelistirmek. Kernel gelistirecegin platformu cok iyi taniman gerekli bir kere, haliyle isin icine bazen elektronik bilgileri bile girebiliyor.
Ornegin PC icin 'hello world' yazan bir kernel gelistireceksen ve QEMU disinda bu kerneli kullanmaya niyetli degilsen bir kere x86'nin (daha dogrusu PC'nin) nasil isletim sistemi safhasina gectigini cok iyi bilmen lazim. Boot sector'u mesela nasil okuyor, nasil kernel'de yazdigimiz koda geciyor, nasil yazdigimiz C kodu ile bilgisayar anlasiyor, stack pointer'i neden (assembly kullanarak) belli adreslere cekmek zorundayiz vs...
Bazi bellek adresleri belli seyleri yapmaya yariyor, mesela 0xB8000 adresi PC mimarisinde VGA text mode'un basladigi bellek adresi; OSDev forumlarina kayit olurken cevaplamam gereken bir soruydu zamaninda.
Butun bunlarin haricinde, isletim sistemini gelistirmeye calistigin zaman bazen mantiksiz bulacagin yerlerde kendi problem cozumlerini uygulayacaksin. Fakat bu cozumler ne derece gelecegi olan cozumler olacak isletim sisteminin gelismesi icin? Ayrica, bazi problemlere cozum bulabilecek misin; ornegin, birisi bir sekilde kernel space'e sizmayi saglayan bir bug buldugu zaman bunu ozumseyip duzeltebilecek misin? Iste tam olarak burada teorik bilgiyi konusturmak ve sana rapor edilen ve bu tarz konulardan oturu rapor edilebilecek olasi bug'lari cozup kapatmak gerekiyor.
Bu teorik bilgi isi tabi isletim sistemi gelistirdikce de oturabilecek bir sey fakat benim bahsettigim, en basit bir seyde bile Google'a soramayacagin veya bir yapay zekaya soramayacagin kisimlar olacak bu konuda, onlari nasil cozecegini bilmekten kastediyorum. Sadece bug olarak dusunme dedigimi yani.
