Linux Kernel Geliştiriciliği İçin Bir Fırsat Daha! - Eudyptula-Challenge

Bir süredir Linux Kernel'a nasıl devam edebilirim diye düşünüyordum. Opw'ye katıldığım zamanlar Coccinelle, Sparse ve checkpatch.pl ile yama gönderdim. Bunun dışında smatch var ama smatch ile test yaparak aldığımız hataları çözmek biraz kafa karıştırıcı. Belki bir süre bir şeyler okumuş olmayı gerektiriyor.

Linux Kernel ile ilgili temel kavramlar var. Rcu'lar, birkaç fonksiyon, birkaç makro bunların hepsini okuyup yama göndermeye devam etmeliyim diye düşünmüştüm. Çekirdekle ilgili şeyleri okuduğumuzda hemen anlamak zor aslında oldukça zor gibi. Hatta insanlar bloglarında "artık çekirdek kodlarını anlayabiliyorum!" şeklinde yazılar paylaşıyorlar :) Bu şekilde ne yapsam diye düşünürken geçtiğimiz ay burada eudyptula-challenge sürecini gördüm.

Bu sürece başlamak için "little at eudyptula-challenge.org" adresine e-posta gönderip katılmak istediğimizi belirtmek yeterli. Peki bu süreç nasıl işliyor? E-posta yoluyla uzaktan bir çalışma gerçekleştiriliyor. Tüm e-postalarımızı otomatikleştirilmiş betikler cevaplıyor. Geliştiriciler ile etkileşim içinde bir çalışma değil. Eğer betiğe parse edemeyeceği ya da nasıl çalışıyorsa uygun bir cevap döndüremeyeceği bir soru ya da yapmamızı istediği dışında bir cevap atarsak bu betik e-postamızı geliştiricilere yönlendiriyor. Geliştiriciler ise birkaç gün içinde cevaplıyorlar ancak mümkün olduğunca geliştiricileri bu süreçle uğraşmak zorunda bırakmadan cevaplar göndermeliyiz.

Bu süreç 20 tane görevden oluşuyor. Temel "Hello World" driverından karmaşık driverlar yazmaya kadar ilerliyor. Gönderdiğimiz cevapları html, base64 gibi formatlarda göndermemeliyiz, çünkü betik parse edemiyor. Bir de genelde dosya eki şeklinde göndermemiz gerekiyor. Tarayıcıdan gmail'den göndermek problem oluşturur diye mutt kullanarak cevap atıyorum.

Bense henüz 5. görevdeyim :) Betik biraz yavaş cevap atıyor, şu an bu sürece 4000+ başvuran var. Bir saat içerisinde cevap attığım göreve bir hafta sonra "Bu görevi geçtiniz." e-postası aldım. Bu yüzden süreç biraz yavaş ilerliyor. Bir de bu süreçte yaptıklarımızı github, blog gibi bir yerlerde yazmamalıyız. Çünkü diğer başvuranlar "kopyala-yapıştır" yapmasınlar diye betik bize en başta belirtiyor ve bize bir id veriyor, cevapları bu id ile gönderiyoruz. Çekirdek için çok fazla yazılmış belge var, 3.10 sürümünde Documentation dizini çekirdek deposunun %4'ünü oluşturuyordu. Bu kadar belge arasından kaybolmadan çalışabilmek biraz zor. Belki bunu görebilmek için bir yerlere yazmayın diyorlar.

Aslında bu muhteşem bir fırsat. Tüm görevleri tamamlayamasak bile bir sürü şey öğrenmiş oluruz. İlk dört süreç aşırı temel. 5. süreçte usb driverları ile ilgili işler yapmak gerekiyor. Sonrasını henüz görmedim :).

Çekirdek geliştiricileri de kendini bu işe verebilecek yeni insanlar arıyorlar. Gerçekten çok büyük bir emek gerektiriyor. Ben meslek olarak değil ama sevdiğim ve kendimi geliştirmek için bir fırsat olarak gördüğüm için başvurdum.

Bu süreçte bir süre kısıtlaması ve acele yok. İstediğiniz zaman görevi tamamlayıp cevabı betiğe gönderebilirsiniz. Ortada bir challenge da yok. Sadece görevleri tamamladıkça cevap atmak ve yeni görevi beklemek yeterli.

Eudyptula-challenge'ın resmi sayfasına buradan ulaşabilirsiniz.

Yeni Başlayanlar İçin Linux Kernel Araçları

Yorucu bir vize haftasının ardından tekrar kendimi geliştirmek için çalıştığım şeylere devam ediyorum. Aslında devam etmeye çalışıyorum çünkü gerçekten çok yorulmuşum :(. Bir de son sınıf olunca sanırım insan kendini daha çok yorulmuş hissediyor.

Linux Kernel için okuduğum şeylere devam ediyorum. Bugünlerde çekirdek geliştiricisi olmanın ne kadar güç bir şey olduğunu anlamam konusunda zirveye ulaşıyorum. Linux Kernel'a yeni başlayanlar için hazırlanan sitelerde hep bu resmin olması da bana bir işaret olabilir :)

Elbette çekirdek geliştiriciliğinin kolay bir şey olmadığının herkes gibi biliyorum. Ancak okuduğum bir yazıyı anlamak için bir kaç kere okumak, her belgenin çok uzun olması, bir çok satırda ne söylenilmek istenildiğini tam anlayamayıp on tane daha yere bakmak biraz yorucu. Bir de hatanın hangi durumlarda oluştuğunu anlayıp, o kod içerisinde oluştuğunu anlayamamak bir problem. Örneğin paylaşımlı veri yapıları ile ilgili problemleri çözebiliriz ancak o veri yapısı paylaşımlı mı nasıl anlayacağız :) gibi.

Aslında geliştiricilik olmasa bile daha güzel katkılar vermek istiyorum. Çünkü çalıştığım ilk bir ayda checkpatch.pl, sparse ve çok az coccinelle kullandım. Bunlar statik ve en temel araçlar.

checkpatch.pl ile gönderilen yamalar geliştiricilerin de okumaktan biraz sıkıldığı yamalar. Sparse ise derleme sırasında hata vermeyen ancak statik yazılım denetimi yapan ve Torvalds tarafından başlatılan bir proje. 

Coccinelle ise tüm bunlardan daha farklı. Kendine özel Smpl (Semantic Patch Languange) ile yazılan anlamsal betiklerden oluşuyor. Cocci kullanırken kendimiz bir hata tipi seçiyoruz. Bu hata tipi sparse, checkpatch.pl ya da başka bir araçla alınan ya da kendi belirlediğimiz bir hata tipi olabilir. Sparse hatalarını .cocci betikleriyle düzeltmek zor. Çünkü Sparse hatalarını çözmek için tek bir standart yok ancak checkpatch.pl öyle değil. Belirlediğimiz bu hata tipi için genelde formal diller adı altında geçen statement, expression, identifier gibi kavramlarla bir şablon oluşturuyoruz. Bu hatanın çözümü için ise yine kendimiz başka bir şablon oluşturuyoruz. Aslında betikte hem hatayı hem de çözümü bir şablon halinde belirtmiş oluyoruz.

Çalıştığım bir aylık süreçte bu üç aracı öğrendim diyebilirim. Bir de smatch var ama ben kendisini hiç kullanmadım :) Bugünlerde ise modüller için dinamik test etme araçlarına bakmaya karar verdim. Hangi araçlar olduğu ve nasıl kullanıldıkları hakkında henüz bir fikrim yok :) ama standart olarak hiç fikrimin olmadığı şeylere en baştan bakıyorum. Bir de çekirdek geliştiricileri çok yoğun olduklarından çok fazla cevap atmıyorlar listelerde ya da irc'de. Bir de sanırım bu kural gibi, sana verilen bir işi listelerde sormadan kendin yapmalısın.

Geçen gün Linux Kernel katkıcısı olmak için düzenlenen Eudyptula Challenge sürecini gördüm. Aslında ortada bir challange yok :) Kendimiz basitten karmaşığa driver yazmaya başlıyoruz. Bu süreçte de her işi kendin yapmalısın ve listelerde ya da irc'de sormayın diye kesin bir şekilde belirtmişler. Bu Opw için de geçerli miydi bilmiyorum. 

Önümüzdeki günlerde Muğla ve Eskişehir'de sunum yapacağım. Döndükten sonra Linux Kernel ile ilgili okuduğum şeylere devam etmeyi ve Sparse, Cocci kullanımının nasıl olduğunu burada yazmayı düşünüyorum.

Linux Çekirdeğine Nasıl Katkı Verilir?

Gnome'un düzenlemiş olduğu Outreach for Women etkinliğine başvuru süreci 11 Kasım'da bitiyor. Ben bu süreçte Linux Kernel için hazırlandım. Geçen yıl Gnome'un kendi araçlarına başvuruyordum ama sürekli bir şeyler derlemek, kütüphane sürümlerini uyuşturmaya çalışmak bir miktar sıkıcı olabiliyor. Bunun için jhbuild ya da Fedora'nın bir sonraki, henüz çıkmamış sürümünü kullanmak tavsiye ediliyor :) Çünkü katkı vereceğimiz Gnome aracının depodaki son hali üzerine değişiklik yapmalıyız. Çekirdek üzerinde çalışmanın nasıl olduğunu bilmediğimden bu sefer çekirdeğe başvurmaya karar verdim.

Opw Kernel sayfasında tüm yapılması gerekenler, okumak için önerilen bir kaç kitap var. Öncelikle örnek olarak ethernet kodu içine printk("..") ile bir şeyler yazdırıp, çıktısını dmesg logunda görmek var. Burada Greg Kroah-Hartman ilk yamanın nasıl yapılacağından bahsetmiş. Temel olarak yama göndermeye kernel.org'dan aldığımız çekirdek kodları dizini içerisindeki drivers/staging'den başlayabiliriz. Buradaki kodların yazılış biçimini düzeltmeyle işe başlayabiliriz. Greg'de linkini verdiğim sunumunda bundan bahsetmiş. Çok temel kodlama biçimi düzeltmeleri yapabileceğimiz gibi, daha karma düzeltmeler de yapabiliriz. Bir de yama gönderirken e-posta konu satırına uyarı çıktısının tam halini yazmamız gerekiyor. Kendimiz uyarıyı yorumlayıp "bu yama bunu düzeltiyor" şeklinde yazdıklarımız genelde kabul edilmeyebiliyor. Bu yüzden tekrar göndermemiz gerekiyor.

Opw Kernel'a başvurmak için bu temel yamalardan göndermek yeterli. Hatta bu yılki Opw projelerinden birisi de kodlama biçimi düzeltme ve Todo dosyalarındaki eksikleri kapatma. Todo dosyalarındaki eksikleri kapatmak biraz daha alt seviye, aslında baya bir alt seviye :). Çünkü yapılması istenenler de o kadar açık belirtilmemiş dosyada. Ben de çekirdek uyarı mesajlarını analiz etme ve iyileştirme projesine başvurdum.

Başlangıç olarak Linux Kernel'a kodlama biçimi düzeltme dışında Sparse ve Coccinelle araçlarını kullanarak katkı verebiliriz. Bu araçlarla drivers/staging altındaki kodları derlediğimizde aldığımız uyarı mesajlarına göre düzeltmeler yapabiliriz. Bir de kodlar içerisinde yer alan Fixme etiketlerinden yararlanarak katkı vermek de yapabileceğimiz seçeneklerden birisi. Katkı verirken zorlanabileceğimiz yanlardan birisi, Linux Kernel ekibi kodlama biçimine oldukça önem veriyor. Bu yüzden aynı yamayı defalarca göndermek gerekebiliyor. Hatta kodlama biçimini test etmek için yazdıkları bir Perl betiği var. Zaten kodlama biçimi düzeltme yamalarını gönderebilmek için bu betiği kullanmalıyız.

Sparse aracı ile fonksiyon tiplerinin ya da değişken tiplerinin doğruluğu, gereksiz fonksiyonları kaldırma, tip dönüşüm işlemlerinin doğruluğu gibi uyarıları analiz edebiliriz. Bu düzeltmeleri yapmak için koddaki fonksiyonları okuyup, çağırılma sıralarını kontrol etmek, kzallac, kmalloc, volatile gibi tiplere, tip dönüşümlerine bakmak gerekli. Çeşitli tiplerin ne olduğunu öğrenmek için burayı okumak faydalı olabilir.

Coccinelle aracını ise ben henüz kullanmadım. Ancak önümüzdeki günlerde onu da denemeyi düşünüyorum. Bir de daha karmaşık hataları çözebilmek için bir kitap bulup okumayı düşünüyorum.

Opw ekibi projede çalışmak için kişi seçerken genelde öğrenci olmamasını tercih ediyor :( . Okul dönemi içerisinde olan bir öğrenci seçmektense herhangi bir işte çalışmayan birisini seçmenin daha verimli olacağı düşüncesindeler. Bu yüzden öğrencilerin Opw yaz dönemine başvurunca seçilme ihtimali daha yüksek. Çünkü proje sürecinde bir işin var mı sorusuna, sınav haftalarını yazmaktansa hiç işim yok yazmak, şansımızı artıran bir etken. Eğer ben de bu dönem kabul edilmezsem, yaz dönemi tekrar başvuracağım.