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.