CV Hazırlama Üzerine Tavsiyeler

Geçtiğimiz günlerde WomENcourage Konferansı'na katılmıştım. Etkinlikteki kariyer fuarında İntel'in standına uğradım. Standdaki çalışanlarla tanışıp, hangi alanlarda çalıştığım hakkında konuşma fırsatı buldum. Standa şu anki açık pozisyonlarından bir kısmının çıktısını alıp, gruplara ayırarak koyduklarını gördüm.

Standda Bev ile iletişime geçtim. Etkinlik akşamı güncel cv'mi ona gönderdim. Bunun üzerine bir Skype görüşmesi ayarladık. Bana sıkı çalışmışsın ama proje detaylarını (amacı, önemi, yararı vs.) yazmamışsın dedi. Bu yüzden cv'min insan kaynaklarında çalışan birine açık olmadığı belirtti.

Bunun üzerine Google Doc belgesi açarak orada cv'mi baştan yazmaya başladık. Açıkçası kendimi tanıtırken etkili cümleler yazmak konusunda pek yetenekli değilim ve bu zamana kadar bunun çok da önemli olmadığını düşünüyordum (hala bir miktar öyle düşünüyorum :p). Bev de bunu fark ettiği için bana çok yardımcı oldu.

Bev'e ilk gönderdiğim cv'yi buradan inceleyebilirsiniz. Birlikte hazırladığımız cv ise burada. Özellikle yurtdışında bir yere başvuruyorsak şu anki konumumuzu belirtmeliyiz. Eski cv'me ek olarak: Profile, Key Skills and Experiences, Project History alanlarını ekledik ve Professional Experiences kısmına açıklamalar yazdık.

Profile kısmında; kendimi kısaca tanıtıp, ilgi alanlarımı belirttim. Key Skills and Experinences kısmında çalıştığım alanları alt başlıklara ayırıp, hangi görevleri üstlendiğimi yazdım. Project History kısmında ise sahip olduğum deneyimleri nasıl kazandığımı yazdım. Şimdi şurada çalışıyorum, daha önce şuralarda çalıştım şeklinde. Bev'in Red Hat'te çalışan bir arkadaşı var. Söylediğine göre o arkadaşı cv hazırlama konusunda çok iyiymiş. Bana yardım etmek için arkadaşıyla iletişime geçeceğini söyledi. Bir süredir arkadaşından gelecek cevabı bekledim (hala bekliyorum) :). Bir aya yakın bir zaman geçince bu yazıyı artık yayınlamam gerektiğini düşündüm. Zaten Bev de cv'min bu halinin eskisine göre çok daha iyi olduğunu söyledi.

Cv'de sen bu cümleleri nasıl hazırladın diye soracak olursak, Bev bir şey yazamadığımı görünce İntel'in iş ilanlarına (ya da başka bir firma) bakarak, kendinde oradaki gibi ilgi çeken cümleler kurabilirsin dedi, zaten yazmama Bev de yardım etti. Yani başvuracağımız şirketin tanımlarına bakıp oraya çok uygunmuşuz gibi cümleler kuruyoruz :p

Cv'de olması gereken diğer şeyler; telefon numarası, kullanmıyorsak bile bir github hesabı linki (mülakata almak için github hesabı olmasına bakan firmalar var), yaptığımız sunumlar varsa onları da eklemeliyiz.

Günlük tutuyor olmak iyi bir cv için gerçekten önemli. Günlükte teknik konularda yazmak, kişinin nasıl öğrendiği, nasıl çalıştığı, hangi yolu izlediği, sonuca nasıl vardığı hakkında karşı tarafa bilgi veriyor.

Bev bana WomENcourage gibi katıldığın başka önemli etkinlik var mı diye sordu, varsa onları da eklememi söyledi.

Eğer hakkında bir miktar bilgimiz olan ama çok uzun süre çalışmadığımız konular varsa "I am familiar with .." şeklinde yazmak gerçekten çok mantıklı :). Geçtiğimiz yıl bir yerde denk gelip görmüştüm.

Yukarıda linkini verdiğim eski cv'yi Rik'le birlikte, Red Hat başvurusu zamanında hazırlamıştım. Bu zamana kadar ne zaman cv hazırlamam gerekse hep gel cv'ni birlikte hazırlayalım diyen birileri oldu. Bu konuda çok şanslı olduğumu düşünüyorum. Bev'le birlikte ilk kez bir İK çalışanıyla cv hazırlamış oldum.

Bev'in arkadaşından da tavsiyeler alırsak bu yazıyı güncelleyeceğim. diff'ini alıp paylaşırım :)

LinuxCon Europe Konferansı

Bu yıl 5-7 Ekim tarihlerinde LinuxCon + CloudOpen + ELC Europe etkinliği İrlanda, Dablin'de düzenlendi. Ben bu sene LinuxCon'a ilk kez ve konuşmacı olarak katıldım ^_^.

Outreachy stajyerlerine çalıştıkları projenin konferanslarından birine katılmaları için etkinlik bileti + $500 burs veriyor. Bu şekilde stajyerlerin iş bulabilme ihtimali de artıyor. Ben de geçtiğimiz kış Outreachy'de stajyer olduğum için bu bursu almaya hak kazandım.

Mümkün olduğunca bu tür etkinliklere katılmaya çalışıyorum. Yeni ülkeler, yeni insanlar görmek gerçekten çok güzel. Hem bu sayede çevremi de genişletmiş oluyorum. Zaten onlar da yeni insanlar tanımaya, konuşmaya çok hevesli.

Bu yıl şöyle bir durum oldu. Linux Vakfı Diversity Scholarship adı altında konferansa katılım bileti vermeye başladı. Outreachy zaten konferansa ücretsiz katılım sağlıyordu ama Julia (Outreachy'de Linux Kernel koordinatörü), bu bursa başvurmamızı önerdi. Biz (stajyerler) de başvurduk ve alındık. İtiraf ediyorum, konuşma yapacağım için alınmayı bekliyordum. Bu sefer şaşırmadım :p

LinuxCon'un ilk günü kayıtlar 7.15'te başladı. Genelde insanlar geç gelseler de biz yeni olduğumuz için vaktinde etkinlik yerinde olduk :). Etkinlik Convention Centre Dublin 'de yapıldı. Orası geçen yıl Dublin'e gittiğimde ışıl ışıl olmasıyla ilgimi çeken yer. Bir sene sonra orada sunum yapacaksın deseler inş. cnm yha derdim :). CCD'nin harika ötesi fotoğrafına bakmak için bu linke tıklayabilirsiniz.

Etkinlikte Julia, Daniel ve Greg ile tanışma fırsatım oldu. Aynı zamanda stajyer olan arkadaşlarla da tanışmış oldum. Etkinliğin ilk akşamı konuşmacılar için düzenlenen yemeğe katıldım. Birkaç servis insanları götürmek için CCD'ye gelmişti. Bu sırada Torvalds gelip önüme oturdu. Tabi bende hafif bir taşikardi ;)

Torvalds servise geldiğinde hafif bir alkış olsa da yanımdaki çekirdek geliştiricileri çekingen gibi duruyorlardı. Bu nedenle ben de Torvalds ile konuşmadım ama Torvalds ile aynı servise binmişliğim var diye cv'me yazayım diyorum.

Konferansta Rik'le (stajdaki danışmanım) görüşmeyi ümit etmiştim. Etkinlik sabahı Rik'e seni göremedim, hangi sunumdasın diye yazdım. Senede 2-3 konferansa katılabildiğim için buna gelmedim dedi. Tabi o böyle diyince içime gnu oturdu :(. Muhtemelen Amerika'da daha fazla etkinlik oluyordur diye düşündüm.

Acaba Sarah Sharp gelmiş midir? diye düşünürken akşama doğru Sarah'nın bu yazısını gördüm. Sarah bilgisayar bilimlerinde birçok kadını destekleyip, cesaretlendirdi. Hala daha devam ediyor. Geçtiğimiz dönem Red Hat'in kadınlar için düzenlediği Açık Kaynak Ödülleri'ni kazanmıştı. Sarah'nın Linux çekirdeği camiasından ayrılması gerçekten üzücü ancak tüm bunlar bir yana, insanın hayatında yer verdiği şeylere bir noktadan sonra dur diyebilmesi bence çok güzel bir davranış.

Geçen yıl gönderdiğim yamalara cevap alamayınca, ilk Sarah'ya sormuştum :). Yanlış bir şey mi yapıyorum, neden kimse cevaplamıyor? diye. Linux çekirdeği merge window sürecinde bu yüzden yeni yama kabul etmiyorlar demişti. O zamanlar Linux çekirdeğinde çok yeniydim (hala çok yeniyim :|) , okuldaki son yılımdı. Alanında lider insanların kendilerini yeni başlayanlara bile konuşacak kadar yakın hissettirmesi gerçekten harika bir şey. Dilerim dünyada daha fazla böyle güzel insanlar var olur.

Bu konudan sonra etkinliğe geri dönelim :p. Etkinliğin ilk günü oldukça heyecanlı ve yorucu geçti. Zaten sabah altıda kalkmıştım (etkinlik 7.15te olunca) :).  İkinci gün üzerimdeki heyecanı, stresi atıp sanki ertesi gün sunum yapacak olan ben değilmişim rahatlığında günümü geçirdim. Genelde Linux çekirdeği ile ilgili sunumlara katıldım, bazı sunumlarda çok fazla bilmediğim anahtar kelime olduğundan anlamakta zorlandım :|. 2. gün SanDisk'in sponsorluğunda kadınlara özel öğle yemeği düzenlendi. Yemek sonrasında kadınların bilişim dünyasındaki yeri, geliştirici topluluklarda kadınların genelde kendini geriye çekmesinden bahsedildi. Günümüzde insanların hala ırkı, rengi, LGTB'ye dahil olmaları gibi sebeplerle dışlandıklarından konuşuldu.

Ben de bu yıl ilk kez 100 kişilik sunum salonlarında 1-2 kadın olmasının nasıl bir durum olduğunu görmüş oldum. Outreachy Linux çekirdeği camiasındaki kadın-erkek dengesini sağlamak için gerçekten çok güzel bir adım. Outreachy'de sadece Linux Vakfı yok elbette. Mozilla, WikiMedia, Xen ve daha fazlası için bknz: katılan organizasyonlar.

Etkinliğin 3. günü Outreachy panelinde sunum yaptık. İlk önce Julia Outreachy'nin genel amaçlarından, nasıl işlediğinden bahsetti. Bu yıl Hindistan'dan gelecek olan stajyer arkadaşlar katılamadılar. İrlanda, Hindistan için vize vermemiş. Nasıl olur insan gerçekten anlayamıyor ama ..

Sunumu dinlemeye gelen kitle beklediğim kadar kalabalık olmadı ama yine de stajyerler olarak heyecandan ölmek üzere sunum yapmış olabiliriz :).

LinuxCon deneyimim benim için yeni insanları tanıyarak, yeni bir şehir hatta yeni bir ülke, mutlu, heyecanlı günler demek oldu. Yapılan sunumların kalitesi zaten gerçekten son zirve. Katılınması itina ile tavsiye edilir :)

WomENcourage Konferansı - 2015

Geçtiğimiz günlerde İsveç'in Uppsala kentinde düzenlenen WomENcourage etkinliğine katıldım. Neden WomENcourage, anlatsana biraz diye sorarsak açalım. Bir süredir Google'ın seyahat bursu verdiği etkinlikleri bu sayfadan takip ediyorum. Beğendiğim etkinlikleri not edip, uygun zamanlarda bursa başvurarak katılmak gibi bir planım var (aslında beğenmediğim etkinlik yok ama naparsın :b). WomENcourage isminden de anlaşılacağı gibi gitmeyi çok istediğim bir etkinlikti. Ancak bu sene LinuxCon'a katılacağım için WomENcourage'a başvurmaktan vazgeçmiştim. LinuxCon 5-7 Ekim'de İrlanda'da, WomENcourage 24-26 Eylül'de İsveç'te oldu. İkisine farklı vizeler gerekiyor ve vize almaya zaman yetmez diye düşündüm.

Bu düşüncelerden birkaç hafta sonra  Google'ın Dablin'deki ofisinden bir eposta aldım. Epostanın içeriği şu şekilde: Daha önce iş arkadaşlarımla görüştüğün için senden haberdar oldum, biz bu sene WomENcourage konferansı için burs vermeye başladık. Başvurmak ister misin? Buradan anladığım kadarıyla geçen sene Dablin ofisine iş görüşmesine gitmemden dolayı tanıdığı söylüyor. İlgili yazı için bknz.: Google Mülakatları

Şansımı denemek için teklifi kabul edip, başvurdum. Başvuru formunda cv dosyası, linkedin hesabı istiyorlar. Herhangi bir soru çözme, kod yazma gibi bir şey yok. Birde hayatta en çok gurur duyduğunuz, heyecanlandığınız proje nedir ve neden en çok onunla gurur duyuyorsunuz gibi bir soru vardı. Ben Outreachy aracılığıyla yaptığım Linux çekirdeği stajımı yazdım.

Başvuru sonuçları açıklandığında bursa kabul edildiğimi öğrendim \0/. Peş peşe iki vize başvurusu gerektiğinden süre yeter mi diye kaygılandım ama her şey beklediğimden daha iyi gitti :). Google seyahat bursunun içeriği şu şekilde, etkinlik için bilet + 1000€'ya kadar masraf bedeli. Herhangi bir fiş sunma zorunluluğu olmadan bu bedeli veriyorlar (ama yinede fişleri ödemeyi alana kadar saklamamı istediler). İsveç için verdikleri burs: konferans bileti + 800€ oldu.

Etkinliğin ilk günü hackathon ve kariyer fuarına katıldım. Ben vardığımda Hackathon'da gruplar ve projeler belli olmuştu. Ben de sayıca az olan bir gruba eklendim :). Projemizin konusu gaz sızmasını en erken şekilde tespit edip, insan hayatını korumaktı. Bunun üzerine proje tasarımı, sunumu ve basit bir simülasyonunu yaptık. Simulasyonu Edison Board kullanarak gerçekleştirdik. Hackathon'da çok yaratıcı olan başka projeler vardı. Düştüğümüzde kimseden yardım alamayacağımız durumlar için uygulama ve şehirde bisiklet sürümünü daha güvenli hale getirmeyi amaçlayan uygulama aklımda kalanlardan.

Kariyer fuarında Google çalışanlarıyla tanışarak burs kazananlara hediye edilen çantayı aldım. Charlie beni Mine'yle tanıştırdı. Mine, Google'ın Londra ofisinde çalışıyor. Orada bizden birilerini görmek gerçekten çok sevindirciydi. Sadece bu kadar değil, Bilkent Üniversitesi'nden Reyyan hoca etkinliğin organizatörlerinden! Birde Uppsala'da yüksek lisans yapan Tuğçe ile tanıştım. Tuğçe, bilgisayar bilimlerinde yüksek lisans yapıyor. Etkinlik akşamı, orada yüksek lisansın nasıl gittiği hakkında konuşma fırsatımız oldu.

Fuarda Intel'de çalışan bir kadınla tanıştım. Bana eposta adresini verip kendisiyle iletişime geçmemi istedi. Bugünlerde onunla görüşüp cv hazırlıyorum, bana bu konuda danışmanlık ediyor. CV hazırlamayla ilgili kısa bir yazı yazmayı düşünüyorum.

Google'da çekirdek seviyesinde çalışmak istersem genelde android tarafında iş bulabileceğimi öğrendim. Birde eğer yurtdışında yüksek lisans / doktora yaparsam, muhtemelen burslu yapacağım, bu konuları konuşabileceğim birkaç kişinin eposta adresini aldım.

Etkinliğin asıl amacı insanların tanışıp, çevre edinmesi olduğundan çok yoğun sunumlar yoktu. En çok beğendiğim sunumlardan biri Facebook'ta çalışan kadının yaptığı sunumdu. Benim de hala aklıma şanslı olduğum için işe alındım, benden başka başvuran kimse yoktu o yüzden aldılar gibi düşünceler geliyor ama aslında öyle değil. Kendime bir şeyleri yaptım, başardım ve alındım diyorum dedi.

Bir diğer sunum ise Anita Borg bursuyla doktora yapan arkadaş oldu. O da alınmayacağını düşündüğü için ilk senesinde bursa başvuru yapmadığını, daha sonra başvurup alındığını söyledi. Bu seneki burs miktarı 7000€ imiş. Üstelik burs sadece doktora için değil, lisans ve yüksek lisansta da başvurulabilen bir bursmuş (sadece doktora için sanıyordum ^_^).

İsveç'te güzel anılar gibi güzel diyebileceğim günler geçirdim. Gezmeye vakit bırakmak için birkaç gün fazla kaldım. Boş olan günümde trenle Stokholm'e geçtim. Tam bir harikaydı. Şehre aşık oldum. Gamla Stan'ı beni buraya gömün diyerek gezdim. City Hall de kesinlikle görülmesi gereken yerlerden. Viking Kuleleri'ne asansörsüz çıkarken yaşanacak durum gerçekten harika. İnsanı sayamadığım kadar yıl öncesine götürüyor :).

Uppsala ve Stockholm'de çektiğim fotoğraflara buralardan bakabilirsiniz.

Stokholm'den sonra LinuxCon için Dablin'e gittim ve sunum yaptım ^_^. Onu da bir yazımda paylaşacağım.

Git'te Yama Uygularken Oluşan Çakışmaları Çözmek

Yazma iznimizin olmadığı depodaki projeye katkı verme işlemini yama dosyası oluşturarak yaparız. Yama dosyaları karşı tarafa yaptığımız değişiklikleri insan okuyabilir şekilde özetler. Bu konu hakkında kısa bir yazı yazmışım, buradan bakabilirsiniz.

Github üzerinden geliştirdiğim kendi projelerime olan katkıları kabul ederken terminal kullanmadan, web sayfası üzerinden hallediyorum.

Linux çekirdeğinde her takım farklı alt dizinlere baktığından ve çoğu github kullanmadığından işlemleri konsol üzerinden yapmak gerekiyor.

Linux çekirdeğinde uzunca bir süredir büyük bir yama  setini kabul ettirmeye çalışıyorum. İnsanlık için küçük olabilir ama benim için büyük demeden geçmeyelim. Yamanın konusu özetle bellek üzerinde büyük bir baskı olduktan sonra swapten dönerken, ihtiyaç duyulmayan sayfaları da swapten belleğe getirip büyük sayfa oluşturarak, performans sağlamak.

Bu yama uzun bir sürece girdiğinden, linux çekirdeği sürekli güncelleniyor ve benim değişikliklerim deponun eski halindeki gibi kalıyor. Bu durumda karşı taraf uygulamaya çalışırken çakışma oluşacak, yama bu nedenle reddedilecek.

Eskiden hep küçük değişiklikler yaptığımdan ve daha kısa süreçte bittiğinden, kendi yamamı güncel depoya uygulama ihtiyacı duymadım. Her satırı tekrar kontrol ederek yeniden oluşturuyordum. Yama büyük olduğunda işler böyle olmadı. Her satırı tekrar oluşturmak çok zor ve derlemede hata almıyorsam bile mantıksal hata yapma ihtimalim çok yüksek.

Değişiklikleri uygulamadan önce git apply --check yama_dosyası şeklinde yamanın uygulanabilir olup olmadığını kontrol edebiliriz. Eğer git apply yama_dosyası komutunu verirsek, yamayı commit yapmadan depoya ekler. Bu durumda değişiklikler commitlenmediği için de git diff ile farkları görebiliriz. Bu bize yama dosyasını ekleyip, commit yapmayarak elle başka değişiklikler yapmaya olanak verir. Tüm değiştirmek istediğimiz dosyalar bittikten sonra kendimiz git commit -a komutuyla değişiklikleri loglayabiliriz.

Yamanın commit yapılarak depoya eklenmesini istiyorsak git am < yama_dosyası şeklinde uygulamalıyız.

Eğer daha önceden yaptığımız commitlerde düzenlemeler istiyorsak git rebase harika bir araç. Onunla ilgili daha önceden bir yazı yazmıştım, buradan bakabilirsiniz.

Yama uygularken geçenlerde karşılaştığım durum, yamanın (muhtemelen) güncel depoyla uyumlu olmamasından kaynaklıyordu. Hata aldığım makine çok sık kullandığım bir makine değildi, belki daha önceki başka bir şeyden kaynaklanıyor da olabilir. Hata mesajı şu şekilde:

Applying: mm: add tracepoint for scanning pages
error: include/trace/events/huge_memory.h: already exists in working directory
error: patch failed: mm/huge_memory.c:2673
error: mm/huge_memory.c: patch does not apply
Patch failed at 0001 mm: add tracepoint for scanning pages
The copy of the patch that failed is found in:
   /home/ebru/linux-stable/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Bunu görünce daha önceden aynı commitler depoda vardı, bu yüzden bir yerde indeksleri tutuluyor düşündüm. mv linux-stable/.git/rebase-apply ..path/ ile rebase-apply dizinini başka bir yere taşıdım. Tekrar yamayı uygulamaya çalıştım yine aynı hatayı aldım (kaldırdığım dizin tekrar oluştu).

Bunun çözümü şu şekilde hatayı aldıktan sonra, git apply linux-stable/.git/rebase-apply/patch --reject komutunu veriyoruz. Bu sayede yamanın çakışma oluşturmayan kısımları depoda oluşturuluyor.

Checking patch include/linux/mm.h...
Checking patch include/trace/events/huge_memory.h...
error: include/trace/events/huge_memory.h: already exists in working directory
Checking patch mm/huge_memory.c...
Hunk #1 succeeded at 30 (offset 1 line).
Hunk #2 succeeded at 2270 (offset 53 lines).
Hunk #3 succeeded at 2307 (offset 53 lines).
Hunk #4 succeeded at 2319 (offset 53 lines).
Hunk #5 succeeded at 2327 (offset 53 lines).
....
       ........
Hunk #13 applied cleanly.
Hunk #14 applied cleanly.
Hunk #15 applied cleanly.
Hunk #16 applied cleanly.
Rejected hunk #17.
Hunk #18 applied cleanly

Bu şekilde uygulanan/uygulanamayan kısımları özetliyor. Uygulamada sorun oluşturan her dosya için uygulanamayan kısımları dosya_adı.rej uzantılı diff dosyası oluşturarak bize gösteriyor. Bu dosyaları git status ile bakarsak görebiliriz. Bu süreçte depo aslında rebase etme gibi git apply sürecinde oluyor. Yamanın uygulanmayan kısımlarına .rej uzantılı dosyalardan bakıp, kendimiz dosyaları açıp değişiklikleri yapıyoruz. git status ile tekrar bakıp eklememiz gereken dosyaları git add ile ekledikten git am --resolved ile işlemi sonlandırıyoruz. Bu şekilde çakışma oluşan yama dosyalarını depoya uygulamış olduk.

Çakışma çözme işlemini bu yazıdan okuyarak öğrendim. Umarım benim yazım da faydalı olmuştur.

Red Hat'te Linux Çekirdeği Geliştiriciliği

Geçtiğimiz kış Outreachy'de Linux çekirdeği üzerinde, Red Hat'te çalışan Rik van Riel'in danışmanlığında staj yaptım.

Staj bitiminde Rik istersen Red Hat'te birkaç pozisyona başvur, ileride seninle birlikte çalışmak isterim dedi. Aslında birkaç sene daha Türkiye'de kalma kararımı Google görüşmesinden sonra vermiştim ama Red Hat'te çalışma düşüncesi de geri çevirilemez bir şeydi, o yüzden kabul ettim.

İlk önce jobs.redhat.com adresinde ilgimi çekebilecek olan işlere baktım. Rik deneyimli çalışan aradıklarını söyleseler bile, yeni başlayan pozisyonunda da iş bulabiliriz dedi. Open Stack, Sanallaştırma ve Arm işlemciler için çekirdek geliştirimi olarak 3 farklı pozisyona başvurdum. Bu üç pozisyon üzerinde de hiç deneyimim yok ancak daha uygun pozisyonlar bulamadım. Zaten onlar da deneyimi olmayan eleman alacaklarını biliyorlardı.

Open Stack ekibi İstanbul'dan taşınman gerekir, bu gibi durumlarda deneyimsiz geliştriciler yerine kıdemli olanları tercih ediyoruz ama sen şansını deneyip mülakatlara gir dedi. Sonrasında kıdemli elemana daha çok ihtiyaçları olduğunu belirttiler, diğer görüşmeleri yapmadık.

Sanallaştırma ekibi aynı zamanda Rik'in çalıştığı ekip. KVM ve Qemu'yu geliştiriyorlar. Sanallaştırma pozisyonu için öncelikle başlangıç görüşmesi yaptık. 2 hafta sonrasına gün belirleyip ilk mülakata girdim. En fazla teknik soruyu ilk mülakatta aldım, sorular zor değildi. Glassador'dan okuduğum kadarıyla Red Hat için soruları zor olmuyor yazıyordu. İlk görüşmede spinlock, zamanlama gibi temel çekirdek kavramlarından sordu. Yeni bir konu olsa da gerçek zamanlı algoritmalar üzerinde yorum yapmamı istedi. Üniversitede en sevdiğim dersler, staj projemde neler yaptığım, bir yamayı kabul ettirene kadar en fazla kaç sürüm gönderdiğim, stajda kabul edilen yamaların çekirdeğin kaçıncı sürümünde olduğu, Rik'le nasıl çalıştığım, kodlamaya nasıl başladığım .. şeklinde devam eden staj sürecimin her evresinden sorular aldım. Görüşme sonunda bir sonraki adıma geçtiğimi öğrendim \0/.

Sonraki adım 5 farklı mühendisle görüşmeyi içeren bir paket gibi. Bu görüşmelerin hepsi aynı günde olmak zorunda değil ve her biri yaklaşık 50 dk sürüyor.

Red Hat görüşmeleri Google'ınki kadar zor değil ve görüşme zamanlarını istediğimiz kadar geniş bir süreye yayamıyoruz. İki görüşme arasındaki süreyi Google pek önemsemezken, Red Hat'teki arkadaş senin yerine başka birini işe alabilirler, bu yüzden görüşmelere ne kadar erken girsen o kadar iyi demişti.

Diğer görüşmeler çok az teknik soru içeriyordu. Genelde stajda neler yaptığım üzerine konuştuk. Bir gün iki görüşmeye birden girdim. O akşam pek yorucuydu diyebilirim. Birde Google görüşmelerinde bu kadar heyecanlanmadım. Sanırım 3. görüşmeden sonra normal heyecanda konuşabildim.

Son görüşmeyi Rik'in içinde bulunduğu takımın yöneticisi olan bir kadınla yaptık. Tüm görüşmeler içindeki tek kadındı. Görüşebileceğim en yüksek mercideki kişiydi.

Son görüşme çok eğlenceli geçti. Bir iş görüşmesinden ziyade bir arkadaşımla konuşuyormuşum gibiydi. Teknik sorular yok denecek kadar azdı. Çanakkale'den, şimdiki işimden, neden çekirdek üzerinde çalıştığımdan, Türkiye'den taşınma durumumdan konuştuk.

Bu görüşmeden bir iki hafta sonra Red Hat'te işe alındığımı öğrendim, Brno'da çekirdek geliştiricisi olarak çalışacaktım.

Birkaç aydır pek iyi değildim, rahatsızlığım zirveye ulaştığında doktora gittim. Şimdilik çok ciddi bir rahatsızlığım yok ancak İstanbul'dan taşınmaya yetecek kadar da iyi değilim, ülkeyi değiştirmek zaten zor bir durum .. Ben bu kararsızlıklar içerisindeyken Red Hat'e de bunu söyledim, taşınmam 4 ay sürer, ben birkaç ay daha geciktirsem gitmeyi derken Red Hat'ten gelen maaş teklifi çok az oldu. Birde taşınma masraflarını zaten karşılamıyorlar. Bir iki firmadan duyduğum kadarıyla taşınma konusunda çok yardımcı olan yerler de var ..

Brno netten gördüğüm kadarıyla pahalı bir yer değil, ancak Red Hat'in €1k'nın biraz altında maaş teklif etmesine şaşırdım. Mezuniyetten sonra bir seneye yakın bir zaman evden çalıştım ve bu zamanı çok da fazla karşılık almayarak geçirdim. Başarılı projelere bu şekilde katkı vermek bir süreliğine benim için kabul edilebilir bir şey. Ancak bunu yurtdışındayken ve sağlığım da şuan için çok iyi değilken kabul etmedim.

Aslında Red Hat kabul etmediğimde evden çalışmayı teklif etti, kabul ettim ancak sonrasında yeni başlayanların bir sene boyunca ofiste çalışması gerektiğini ve ilk yıldan sonra evden çalışma izinlerinin olduğunu söyledi. Neticede maaş ve rahatsızlığım nedeniyle kabul etmemiş oldum. İk'daki arkadaşa Brno'da çalışmayı İstanbul'da birkaç sene çalıştıktan sonra olsaydı kabul ederdim, dedim. Daha sonraki bir zamanda eğer çalışmak istersem kendisiyle iletişime geçmemi istedi.

Bugünlerde kendime iyi bakıp, daha sağlıklı yaşayarak hayatımı düzene oturtmaya çalışıyorum. Zaten öğrenciyken de yaşama şeklimi değiştireceğim diyerek kendime bu sözü vermiştim. Ben bu sözü tutmaya başlamadan önce, vücudum bana uyarıyı verdi :p. Aslında çok önemli şeyler değil ama çok geç saatlere kadar uyanık kalmamak, az tuzlu yemek, sağlıklı beslenmeye çalışmak gibi okul temposundan sonra daha normal koşullarda çalışmayı düşünüyorum :).

Yurtdışına yine giderim, sonraki zamanlarda karşıma daha iyi koşullarda başka fırsatlar çıkar diye ümit ediyorum.

Google Mülakatlarına Hazırlanma Süreci

Geçen yaz Google ik'dan (insan kaynakları) profilinizi linkedin, github ve birkaç listeden inceledik kabul ederseniz başlangıç bir görüşme yapmak isteriz içerikli bir e-posta aldım. 2 gün sonra başlangıç telefon görüşmesini ik ekibinden bir arkadaşla yaptık. Görüşmenin 45-55 dk arası sürmesi bekleniyor, benim bir saati biraz geçmişti. İlk görüşmede kod yazmamı gerektirecek bir şey sormadılar. Veri yapıları, ağ bilgisi, bit düzeyinde işlemler, algoritmalar ve karmaşıklıkları, bash komutları, sistem çağrıları, süreçler hakkında sorular geldi. İlk görüşmede tanışma, ilgi alanlarını öğrenme, hangi işler üzerinde uğraştığın hakkında bilgi edinme gibi kısımlardan da konuşulduğu için teknik değil olarak adlandırıyor ancak bence gayet teknikti :). Görüşme sonunda, ilk adımı geçtiğimi öğrendim.

Daha önce bir iş tecrübem olmadığı için bir alan seçmem gerekiyordu, telefondaki arkadaş Site Reliability System Engineering (SRE) ve Software Engineering olmak üzere 2 pozisyon sundu. Bilgilerin sistem tarafı için daha uygun istersen SRE seç şeklinde öneride bulundu. SRE görüşmelerinde daha başarılı olacağımı düşündüğümden onu seçtim.

Başlangıç görüşmesinden önce çok gerildim, zaten nasıl konuşacağım kısmı ayrı bir olay :). Soruları bitirdikten sonra, görüşmeyi yapan arkadaş diğer adımlar için tavsiyelerde bulundu, sorular üzerinde sesli düşün, eğer ne sorulduğunu anlayamadıysan bilmiyorum deme, anlayana kadar sorman sorun değil, dedi. Çünkü söylediği bir kelimeyi anlayamadığımdan bilmiyorum demiştim, anlamadığımı fark etti ve gtalk'a sorunun bir kısmını yazdı ve cevapladım :).

İkinci görüşmeyi bir mühendisle yine telefon üzerinden yaptık. Kodlama soruları için google doc kullandık. Görüşme yine 45-55 dk arasıydı. Soruların neredeyse hepsi çalıştığım sorulardı ancak düzenli ifadelere çok fazla çalışmaya vaktimi yetiremedim. Görüşmede son soru basit split, join işlemleriyle çözülebilecekken suçluluk psikoljisi ile düzenli ifadelerden çözülmesi gerekiyor sandım :). Çözüme yaklaştım ancak çoğu şeyi göz ardı ettik, ben ifadeleri karıştırdım gibi şeyler oldu. Görüşme sonunda mülakatı yapan arkadaş, bu görüşmenin büyük kısmını harika yaptın dedi. Bir an şok olmamla birlikte havaya uçup geri oturdum :).

Google'ın mülakatlarına hazırlanırken aşağıdaki linklerden yararlandım. Bunlar dışında deneyimler üzerine yazılmış çok fazla blog yazısı bulabilirsiniz. Hepsini okumak belki mümkün olmaz ama çoğunu okuyun gerçekten çok faydalı oluyor. Mühendislerle yaptığım görüşmeler ik'daki arkadaşla yaptığım görüşme kadar eğlenceli geçmedi. İk'da olan arkadaş görüşme sırasında harikasın, çok iyi gibi sürekli destek olarak ve çok sevecen bir şekilde konuşuyordu. Ancak mühendisler süreci soğuk, sadece soru soran ve cevap bekleyen bir şekilde geçiriyorlar. Okuduğum bir blog yazısında telefonda problem olduğu için Skype'a geçmek zorunda kalan bir arkadaş mühendis soğuk ve sıkılmış görünüyordu yazmıştı. Bu yüzden telefondaki soğuk tavırları hiç üzerime alınmadım :), sadece en sonda tebrik eden bir ifade duydum.

Siteler: Geeks For Geeks, Glassador, Careerup, Cracking Code Interviews, System Design, Devops Interview Questions.

3. mülakat için yeniden tarih belirledik. Genelde 3 er hafta arayla yaptık görüşmeleri. İlk iki görüşmem iyi geçtiğinden sonuçlarını hemen öğrenmiştim, normalde bir haftayı bulabiliyor. Görüşmelerin arasını çok uzatmak bence iyi değil, sonuna kadar gidebileceğimizi düşünürsek insan bunalabilir. 3 hafta gayet iyi bir süreç. Zaten görüşme 45 dk sürüyor, en fazla kaç soru sorabilir diye görüşmeden önce kendimizi rahatlatmak da bir yöntem :). Birde hazırlanırken süremi bir hafta kadar tanım sorularına çalışarak, bir hafta kodlama sorularına çalışarak sonraki hafta bunları karmaşık tekrar ederek geçirdim.

3. görüşme görüntülü olacaktı ancak ne olduysa yine telefon üzerinden yaptık. Bu görüşmede sorular beklediğim gibi değildi. Temelde bir soru sorup, diğer soruları aynı soru üzerinden türetti. Görüşmenin nasıl geçtiğini anlamadım, soyut şeyler üzerinden benim daha önce deneyememiş olacağım şeyler üzerinden konuştuk. O zamanlar her görüşmenin bitiminde sonucu söylüyorlar sandığımdan bu adımı geçebildim mi? diye sordum, henüz bilmiyorum cevabını aldım :). Bir hafta sonra geçtiğimi öğrendim.

Buradan sonraki adım Google ofisinde yapılması gereken görüşme. Yine ik'daki arkadaş önce aradı sonra aynı bilgileri e-posta ile gönderdi. Birkaç Google pozisyonu önerdi, Dublin'de olanı seçtim, Dublin aynı zamanda Google'ın Avrupa'daki ofislerinin merkezi. Vize işlemleri nedeniyle ve benim gideceğim haftada Dublin'de etkinlikler olduğundan, son görüşmeyi 1,5 ay kadar ertelemek zorunda kaldık :(.

Son mülakat 45'er dakika şeklinde ve 5 oturumdan oluşuyor. Her oturuma 1 ya da 2 mühendis girebiliyor. Son oturumu SRE takımının yöneticisiyle yaptık ^_^.

Son aşama gerçekten çok heyecanlıydı. Uzaktan yapılan görüşmeler sırasında sesin kesilmesi problemi çok oluyor. En sonunda duyamıyorum, sesin kesiliyor dediğimde google doc'a soruyu yazdıkları olmuştu. Yüzyüze görüşmede çok hızlı konuşurlarsa diye sıkıntım vardı ancak öyle olmadı. Google çalışanları konuşma konusunda diğer şirketlere göre çok daha anlayışlı. Oldukça anlaşılır konuşuyorlar.

Konuşma pratiği yapmak için dil kurslarına gitmek faydalı, birde Google SRE ekibinin düzenlediği etkinlikleri youtube'dan çok rahat bulabilirsiniz. Ben onları izlemiştim, hem birkaç anahtar kelime öğrenmemi sağladı hem anlamamı geliştirdi.

Mülakatın yapılmasından bir gece önce Dublin'deydim. Sabah ik'daki arkadaş istersen otelden seni alayım, yürüyerek gayet yakın dedi. Kabul ettim, çok yağmurlu bir sabahta ofise birlikte gittik. Her oturumdan sonra 3-5 dk beklemek gerekebilir, bu sürelerde eğer odada yalnız kalırsam dışarı çıkmamamı ve henüz çalışan olmadığım için ofiste tek gezmememi söyledi.

Son görüşmede soruların çoğunluğu çalıştığım yerlerden çıkmadı. Bu kadar sorulmaz ya dediğim ve ayrıntısına inmediğim şeylerden çıktı. Açıkçası hiç beklememiştim. Daha önce bir yerde de öyle soruları görmedim :(. Basit sorulan sorular da vardı elbette ama geneli değildi. Çok iyi veri yapıları soruları bekliyordum, hiç sormadılar :|.

Ancak sürecin tamamı çok heyecanlı ve cesaretlendiriciydi. Yüzyüze yaptığımız görüşmelerdeki arkadaşlar da çok sevecendi, bir soğukluk yoktu :). Birde yurtdışına ilk seyahatimi Google sayesinde yapıyor olmam da çok mutluluk vericiydi.

Google'ın sizle görüşmek isteriz şeklinde e-posta atması için sadece bir github hesabımız olması bile yeterli. Çünkü onlar da yeni insanlar tanıyıp, onları görüşmelerine hazırlamak istiyorlar.

Üniversiteden "olmadı sanırım .. olduğu kadar :(" şeklinde hissederek mezun olmuştum, bunun üzerine Google görüşmesinin bu kadar ilerlemesi çok iyi oldu, çok da güzel oldu :). Mezuniyetimden sonra 7-8 ay boyunca kadar her şey böyle karmaşık ve heyecanlı bir şekilde ilerlerdi. Bir hafta önce bundan sonrası şöyle olur muhtemelen dediğim şeylerin hiçbiri tutmadı :), şimdi tekrardan her şey düzene girdi. Bundan sonrasında yine Linux çekirdeği üzerinde devam edeceğim. Belki bir gün yine Google ile görüşebiliriz :).

Dublin'de 2 gece kaldım ve çok gezemedim. Bir dahaki sefere daha fazla kalabilirim diye düşünüyorum. Dublin'de çektiğim fotoğraflar için buraya bakabilirsiniz.

Linux Stajı Sonucunda

12 Mart sonunda Outreachy (OPW) kış dönemi stajları sona erdi. Ben bu süreçte bellek yönetiminde, THP (transparent huge page) kodları üzerinde çalıştım. Birlikte çalıştığım danışmanımın istersen bir süre daha birlikte çalışmaya devam edebiliriz demesiyle şimdi hala devam ediyorum :).

Staj sürecinde sadece okunur sayfalar, sıfır içerikli sayfalar (zero page, bellekte henüz eşleme yapılmamış sadece okuma isteği almış ve veri içermeyen sayfa) ve swap cache üzerinde çalıştım. Swapteki veriler için birini stajdayken diğeri stajdan sonra olmak üzere iki yama hazırladım. İkisininde ortak yanı do_swap_page kısmında takılıyor olmaları ^_^. Sistem bazen askıda kalıyor, bazen boot aşamasında bile bir panik oluyor gibi problemleri var hala. Koddaki sayaçların değerini daha iyi görebilmek için tracepoint yazdım. Tracepointi de ayrı bir yama olarak göndereceğiz. Askıda kalma problemleri için en iyi yöntemler ise serial console ya da netconsole kullanmak. Geçen gün Sarah Sharp'ın günlüğüne bakarken burada bir netconsole yazısı gördüm :). Askıda kalma olayı genelde spinlocklarda bir hata yaptıysak oluşuyor.

Outreachy'de, Linux Vakfı kendi stajerlerini 5 dakikalık kısa konuşma yapmak için Linuxcon'a davet ediyor. Ben Dublin'de olana katılacağım, Seattle'da olan biraz fazla uzak. Zaten bu ara hangi etkinliğe gitmek istesem hep Dublin'e denk geliyor, aslında ben mümkün olduğunca başka şehirler seçmeye çalışıyorum :).

Nisan başında lwn.net'te stajımla ilgili bir yazı yayınlayacaktık, yazının taslağı hazır, sanırım swaplerle olan işler bittikten sonra onları da ekleyip yayınlayacağız.

Bu staja alınmam benim için biraz sürpriz gibi oldu. Necdet hocanın hadi Ebru başvursana demesiyle başvurdum ve çok iyi oldu, çok da güzel oldu :).

Mezuniyetimden beri evden çalışıyorum, bu biraz değişik oldu. Muhtemelen bir ay daha evdeyim, sonra bir süre çekirdeğe ara verip başka işlere bakıp, sonrasında tekrar döneceğim :). Çekirdek üzerinde çalışmanın diğer alanlara göre daha fazla dikkat gerektirdiğini düşünüyorum. Çünkü bir yerde hata yaparsam o değişikliği geri almak daha uzun sürüyor, daha fazla şeyi kontrol etmem gerekiyor.

Staj sürecimde işini çok iyi yapan insanlarla birlikte çalıştım. Rik, 12 senedir Linux üzerinde çalışıyor. Bunun ilk duyduğumda bir yutkunma .. :).

Aslında üniversiteye başladığımdan beri hep işini çok iyi yapan, hayran olduğum insanlarla bir aradayım. "Harika insanlarla birlikte çalıştım" diyebilmek, bu hayattaki en güzel şeyler arasında ilk sıralarda yer alır. Çomü'de bilgi işleme gitmeye başladığımdan beri ben de bu sözü söyleyebiliyorum ve iş hayatında da böyle devam eder diye ümit ediyorum :).

Linux Çekirdeğine Tracepoint Eklemek

Linux kaynak kodunda değişiklik yaptıktan sonra, bunları izlemek için farklı yollar var. Ben henüz çok değişik bir şey kullanmadım. Bu zamana kadar hep printk ile kern.log'a aktarıp, sonra grep, wc, tail, split gibi komutlarla inceleme yapıyordum. Aslında çok farklı şeyler kullanırım sanmıştım :) ama danışmanım ilk olarak bu yöntemi önerdi.

kern.log'u incelemek sandığım kadar rahat olmuyor, her adımda kodun patlamadığından emin olmalıyım. Bu yüzden bir sürü şey yazdırıyorum, gerçi panik olduğunda otomatik olarak loglara düşüyor ama bazı askıda kalma durumlarında düşmeyedebilir. Birde her testten sonra log dosyasını boşaltıyorum sonra içinden bir şeyler parse etmek zorlaşıyor, sadece 1 test için dosya boyutunun 15M olduğunu hatırlıyorum. kern.log'u boşaltmak için bir yöntem olarak "sudo tee /var/log/kern.log < /dev/null", bunu kullanabiliriz. Hiç boşaltmadan test yapmaya devam ettiğimde dosya boyutu .. ^_^. Elbette inceleme yapılamayacak kadar büyük oluyor diye bir düşüncem yok ama zorlaştırmasak iyi olur.

Uzunca bir süredir yaptığım değişikliklerde beklenmedik sonuçlar görüyorum, aslında beklenmedik sonuçlar görmek elbette en beklendik şey :P, ilk zamanlar test yaparken her testte farklı bir sonuç görürdüm. Danışmanımın emin misin bunu gördüğüne, o zaman şunu da ekle demesine neden olmuşumdur, sonra başka bir testte ben yanlış bakmışım problem o değilmiş şeklinde döndüğüm çok olmuştur :). Ancak bu sefer öyle olmadı, ben uzunca bir süre hep aynı beklenmedik sonucu aldım. Bu durumda oluşabilecek ihtimaller, 1- ben yanlış bakıyorum, 2- pteleri swapten çektiğim halde hala bir şeyler onların swapte gibi loglanmasına neden oluyor, bunun nedeni belleği mantıklı kullanmak ya da tekrar swape gitmesi gerekirse daha az işlem yapmak istemeleri olabilir.

Test yaparken 800M'lık verinin üzerindeki değişimlere bakıyorum, büyük sayfalar 2M olarak tutuluyor. Tek bir büyük sayfa için 512 kere (normal sayfalar 4kB) döngü yapılıyor, benim de her döngüde 15 satıra yakın yazdırdığımı düşünürsek, bu durumda loglarda gözümden bir şey kaçmamıştır demek pek mümkün değil :). İşte tam bu gibi problemler için tracepoint'ler var.  Tracepoint eklediğimiz her fonksiyon için bir kez çalışıyor, aslında değişkenlerin son değerini, kodun sonuna printk ekleyerek de yazdırabiliriz. Ancak bu yöntem boş yere kern.log'u dolduruyor ve kendi testlerimiz için eklediğimiz printk'lar ile birlikte upstream'e yama gönderemeyiz zaten, yani göndermesek iyi olur :). Tracepointler; printk ekledim, eklemeyi unuttum (bir daha derle), upstreame göndermeden önce printk'ları kaldır bir daha derle - test et gibi şeyleri önlüyor. Tracepoint kodu yazıyoruz ve bir kere derliyoruz, sonra eğer o değişkenlerin değerine bakmak istersek perf aracı ile testleri çalıştırıyoruz ve değerleri görüyoruz :).

Tracepoint Nasıl Tanımlanır?

Daha önceden tanımlanmış tracepoint kodlarını inceleyebiliriz. Birde lwn.net'te çok açık anlatan yazılar var. Örneğin vmscan.c'deki birkaç fonksiyon için tracepoint ekleyeceğiz. Bunun için  include/trace/events/'de vmscan.h dosyası oluşturmalıyız. Tracepoint yazmak için yapmamız gerekenler: 1) temel tanımlamaları yapmak, 2) TRACE_EVENT() tanımlamak, 3) TRACE_EVENT içerisinde belirttiğimiz fonksiyonu kaynak kodda çağırmak.

#undef TRACE_SYSTEM
#define TRACE_SYSTEM vmscan

#if !defined(_TRACE_VMSCAN_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_VMSCAN_H

TRACE_EVENT(....
                             .....
);

#endif /* _TRACE_VMSCAN_H */
#include <trace/define_trace.h>

Şimdi TRACE_EVENT() içeriğini tanımlayalım:
TRACE_EVENT(name, proto, args, struct, assign, print)
name: Kaynak kod içerisinde çağırılacak fonksiyonun adı.
proto: Fonksiyon için prototip.
arg: Fonksiyonun alacağı değişkenler.
struct: Tracepoint içine geçen verilerin depolanması için yapı.
assign: Değişken ataması yapmak için kullanılıyor.
print: Değişkenleri yazdırmak için kullanılıyor.

Yazdırmak istediğimiz değişkenler sadece struct shrinker *shr ve unsigned long lru_pgs değişkenleri olsun:

TRACE_EVENT(mm_shrink_slab_start,
    /* proto */
    TP_PROTO(struct shrinker *shr, unsigned long lru_pgs),
    
    /* arg */
    TP_ARGS(shr, lru_pgs),

   /* struct */
    TP_STRUCT__entry(
        __field(struct shrinker *, shr)
        __field(unsigned long, lru_pgs)
    ),

    /* assign */
    TP_fast_assign(
        __entry->shr = shr;
        __entry->lru_pgs = lru_pgs;
     ),

     /* print */
     TP_printk("shr = %p,  lru_pgs = %ld",
                       __entry->shrink,
                       __entry->lru_pgs)
);

TRACE_EVENT içerisinde mm_shrink_slab_start şeklinde belirttiğimiz fonksiyonu, vmscan.c dosyasından, önüne trace_ ekleyerek bu şekilde çağırıyoruz: trace_mm_shrink_slab_start(shr, lru_pgs); Bu değişkenler için sırasıyla proto, arg, struct ve assing'ı tanımladık. Daha sonrasında print ile yazdırma kısmını ekledik.

vmscan.h dosyasının tüm içeriğine buradan bakabilirsiniz. Dosya içerisinde event_class, define_event gibi tracepoint'leri gruplayarak tekrara düşmeyi önleyen makrolar kullanılmış. Ben henüz bunlara gerek duymadım. Tracepoint kullanmak için yukarıda belirttiğim 3 temel maddeyi yapmak yeterli.

Kaynaklar: https://www.kernel.org/doc/Documentation/trace/tracepoints.txt

                   https://burzalodowa.wordpress.com/2013/07/09/linux-kernel-tracing/

                   http://lwn.net/Articles/379903/

Sparse Nasıl Kullanılır?

Sparse, Linux çekirdeğine katkı verirken kullanılabilen araçlardan biri. Linus Torvalds tarafından yazılmış statik kod denetleyicisi ve bir süredir de bakımını Josh Tripplett yapıyordu.

Normalde çekirdek derlemesi yaparken almadığımız hataları/uyarıları Sparse'ı etkinleştirerek alabiliriz. Peki Sparse bize ne tür hatalar döndürüyor? Makro kullanımlarındaki yanlışlıklar, tip dönüşüm hataları, static & extern gibi anahtar kelimelerin kullanımlarında yanlışlık varsa ya da bir fonksiyon üretildiği ve hiç kullanılmadığı durumlarda uyarı veriyor.

Kurulum için sparse paketini kurmak yeterli ya da depodan çekerek de kurabiliriz. Temel kullanımı ise şu şekilde: make C=2 drivers/staging/wlan-ng/ 

Sparse'ı kullanabilmek için çekirdek hakkındaki en temel veri tiplerini, makrolarını bilmek gerekiyor. Eğer static, extern ifadelerindeki kullanımları düzeltmek gerekiyorsa o fonksiyonların nerelerde çağrıldığına, hangi başlık dosyasında tanımlandığına bakıp düzeltme yapmak gerekiyor. Ben sparse'ı ilk kullanmaya başladığımda bu yazıyı okumuştum, zaten okumamla birlikte oldu o zaman, beni evden beklerler demem bir olmuştu :). Sparse ile katkı vermeye başladığımda da artık beni evden beklemiyorlar demeyi unutmadım tabi ^_^.

Sparse kullanırken veri gösterimlerindeki hataları da alabiliriz. Eğer driver Makefile dosyasında endian kontrolleri etkinleştirilmediyse, sparse kullanırken  make C=2 CF="-D__CHECK_ENDIAN__"  drivers/staging/wlan-ng/  şeklinde bayrağı aktif etmeliyiz.

Verileri big endian ya da little endian şeklinde göstermek tasarımcıya göre değişen bir şey. Veri biçminde anlaşabilmek için işlemcinin kullandığı yerel biçimden driverın kullandığı biçime dönüş yapmak gerekebiliyor. Bunun için cpu_to_le16(), ya da le16_to_cpu() fonksiyonları var. Bu fonksiyonlar little endian 16 bit olan veriler için. Veri gösterimiyle ilgili fonksiyonlara buradan ulaşabilirsiniz. Birde burada örnek var, gayet yararlı olduğunu düşünüyorum :). Burada temel problem fonksiyonların aldığı değişkenler ya da atama işlemlerinde meydana gelen tip uyumsuzlukları. Bu gibi durumlarda değişkenin tipini değiştirmek ya da dönüştürme işlemini kaldırmak gerekiyor. Ya da driverın özelliklerinden ve kodu inceleyerek, veri aktarımı olurken hangi biçime dönüştürülmesi gerektiğini anlayabiliriz. Ağlarla ilgili olan driverlarda big endian gösteriminin kullanılması gibi.

Couchbase 2.x İçin nagios-plugin-couchbase Güncellemesi

nagios-plugin-couchbase, iki yıl önce Necdet Yücel'in düzenlediği Yakından Eğitim ile ortaya çıktı. Bu projeyi Kaan'ın danışmanlığında geliştirdim. Daha önce kullanmadığım Nagios, Couchbase'i kullanmam ve NoSQL kavramlarını öğrenmem bakımından oldukça faideli bir proje olmuştu :).

Projeye ilk başladığımız zamanlar geliştirimi Couchbase 2.0 üzerinde yapıyordum. Şimdi Couchbase 2.x serisi kararlı halde ve 3.0'ın beta aşamasındalar. Ben de eklentiyi güncelledim ve artık Couchbase 2.x ile uyumlu diyebiliyorum :).

Eklentiye birkaç yama gönderilmişti onları aldım, bir de her güncellemede yeniden .cfg oluşturması uzun sürmesin diye örnek bir dosya ekledim. Bu arada proje aynı zamanda nagios-exchange'de de yer alıyor ^_^.

Bu projeyi geliştirmemi sağlayan Yakından Eğitim ekibine teşekkürler.

Richard Stallman - Telif Hakları Sunumu

Bu sene Stallman Türkiye'ye geldi. İstanbul'da iki sunum yaptı ve Bilmök'te bir sunum daha yapacak. Etkinlik hakkında bilgi için buraya bakabilirsiniz.

Ben Sabancı Üniversitesi'nde yapılan Telif Hakları konuşmasına katıldım. İlk defa bu kadar büyük bir insanın yaptığı konuşmaya katıldım, çok mutluyum. İstanbul Avrupa tarafında oturmam ve etkinliğin Tuzla'da olması nedeniyle 09:30da yola çıktım ama olsun :). Sabah Kadıköy'de Gülçin ile buluşup servisle etkinliğe gittim. Bu kadar zaman sadece sosyal ağlardan konuşma fırsatı bulduğum insanlarla yüz yüze görüşmek de heyecanlı oluyor.

Etkinliğe muhtemelen kapılar kırılır, ortalık yıkılır düşüncesi ve Necdet hocayla (ve ekibiyle) daha fazla vakit geçirmek için bir saat erken gittim. Necdet hocayı ve arkadaşlarımı görme kısmı tamamdı ancak böyle bir etkinlikte dolup taşıp oturmaya yer olmaması gibi bir durum beklerdim, olmadı. Salon doluydu ancak yine de beklediğim hararet yoktu.

Stallman konuşurken "bu konuda en mantıklı böyle düşünebilirdi" düşüncesi aklımda oluştu. Aslında Necdet hoca da bize okulda yıllardan beri Stallman'ın felsefesinden, görüşlerinden bahsediyor. Stallman konuşurken "Necdet hoca da bize bunlardan bahsetmişti" şeklinde hatırladım. Stallman'ın bize bahsettiği noktalar:

- Özgürlük nedir? Özgürlük yazılım açısından nedir?
- Özgürlük kod içeriği şöyle olmalıdır, böyle güvenli olmalıdır, gibi şeyleri göz önüne almaz, kullanıcının onu değiştirebilmesi, dağıtabilmesi anlamına gelir
- Özgür olmayan yazılımlar oluşturulmamalıdır
- İnsanların sahip olduğu yazılımları paylaşma hakları ellerinden alınmamalıdır
- Eğer bir sistem içerisinde özgür olmayan başka yazılımlar da varsa o sistem özgürlüğünü kaybeder

Bunun dışında tersine mühendislik hakkında da güzel şeyler söyledi. Üniversitelerde ders olarak verilmesi gerektiğinden bahsetti. Bir de Torvalds hakkında da .. :(. Bu ara Linux Vakfı'nda staj yaptığımdan yine de öyle demesek mi şirinliğinde dinledim :). Torvalds'ın Gnu projesini de kullanarak bir çekirdek oluşturduğunu ve Gnu içerisinde bir boşluk oluşup Linux'un geliştirildiğinden bahsetti.

Etkinlik başlarında Gnu is not unix şakası oldukça döndü. Bu cümleyi ilk okuduğum zamanı dün gibi hatırlıyorum. 2. sınıftayken Gnu ne acaba diyip What is gnu yazdığımda gördüğüm ilk cevap Gnu is not unix olmuştu. O zamanlar çok yeni olduğumdan "hmmm .. Pek anlamadım, bir daha okuyalım, Gnu is not unix .. hmm ..". O halim de pek şirindi ;).

Etkinliğin sonlarına doğru Gnu peluş oyuncak açık artırmaya sunuldu ve sahibi elbette ki Necdet hoca oldu. Aslında yedi kişi bir Gnu'ya girsek de olabilirdi ama .. :).

Açık artırmadan sonra dinleyicilerin sorularına yer verildi ve soranların bir kısmı Stallman'ın aslında iddia etmediği şeyleri sanki Stallman öyle düşünüyormuş gibi sordu. Düşünceler hakkında böyle düşünmek de yanlış olmaz mı, ya da şöyle düşünebilir mi şeklinde sorulmasını anlarım ama salonda ben haklıyım şeklinde yapılan konuşmalar vardı. Stallman'ın buna verdiği cevap beni dinlemeye gelenler bana katılmayabilir ne yapabilirim oldu :).

Etkinlik çıkışında Necdet hoca ve öğrenci/mezun grup birlikte vakit geçirdik. Dün Kaan'ın da söylediği gibi ben biraz neşe saçmış olsam da çok güzel bir gündü. Aşağıda etkinlikten fotoğraflar, Stallman ile topluca fotoğraf çektirdik :)

Linux Kernel Ekibiyle Staj

Geçtiğimiz yaz haziran sonunda mezun oldum. Mezuniyetten sonra bir işe girip çalışmak, her gün işe gidip gelmek, birkaç ay işim dışında bir şeye bakmamak, sonrasında iş temposuyla birlikte neler yapabileceğime karar vermek gibi bir düşüncem vardı. Ancak tabi ki böyle olmadı :).

Ağustos başında Google İrlanda ofisinden iş görüşmesi için e-posta aldım, benim ile başlangıç bir telefon görüşmesi yapmak istediklerini söylediler. Hemen kabul ettim. İlk üç aşamayı geçtim, son görüşme için Irlanda'ya gittim ancak son görüşmede başarılı olamadım. Sorular beklediğim gibi değildi, internetten çalıştığım gibi de değildi.

Ben evde son görüşmeye hazırlanırken Gnome OPW için başvurular da başlamıştı. Ben daha önce ilk Gnome'un araçlarına sonra da Linux Kernel'a başvurmuştum. Gnome'a katkı verirken katkı vermek için masaüstü bilgisayarınızda ortam oluşturmak zor. En son Fedora 19'un alfa sürümünü kullanmak zorunda kalmam ve alfanın hiç kullanışlı olmaması üzerine katkı vermeyi sonlandırdım :). Aslında jhubild'de kullanabiliriz ama onda ortamı hazırlaması .. bana bir tane geliştiricisi o zamanlar Fedora beta sürümü varken, beta kullanmamı önermişti, beta yine kullanılabilirdi ancak bir sonraki sürüme geçtiklerinde alfa kullanmak zorunda kalmam pek iyi olmadı. Bir de Gnome Continuous var, onu yeni gördüm ama henüz denemedim.

Linux Kernel'a katkı verdiğim sene aslında alınmayı beklemiştim gerçekten ama olmadı. Bu dönem başvuru süresi 2 ay gibi uzundu :), geçen sene 3 hafta gibi bir süreydi. Necdet hoca "Aslında sen başvursan çok şey yaparsın" dedi, ben de başvurdum ve alındım :). Alınmayı gerçekten beklemiyordum ve çok güzel bir sürpriz oldu.

Şimdi Rik van Riel ile birlikte bellek yönetimi üzerinde çalışıyorum. Bellek yönetimi katkı vermeye başlamanın en zor olduğu kısımlardan biri, çünkü çekirdeğin temel fonksiyonlarını içeriyor ve daha karmaşık. Başvurduğunuz projeye göre staj sürecinde ne kadar yama gönderebileceğinizin sayısı da değişiyor. Ben projem zor olduğundan, 4 ayda otuz satır yazabilir miyim derken şimdiden bir yamayı kabul ettiler bile :).

Linux kaynak kodunda bellek yönetimi ile ilgili dizin mm/. Eğer güncel mm dizinini takip etmek istiyorsak da Linus Torvalds'ın kullandığı dalı değil de linux-next'i takip etmek gerekiyor. Yamaları Andrew Morton kabul ediyor ve günlük olarak etiketliyor. Güncel linux-next'i nasıl takip edeceğinizi görmek için buraya bakabilirsiniz.

Anladığım kadarıyla, Linux'ta bellek yönetimi üzerine çoğunlukla Redhat ekibi bakıyor, çünkü birçok sunumu ve belgeyi o ekip hazırlamış. Ben yamaları gönderirken mm dizini bakıcılarına baktığımda genelde @redhat.com alan adlı hesaplar var. Yamaları vger.kernel.org ve  akpm@linux-foundation.org listelerine gönderdiğim için de çok mutluyum. O kadar büyük listelerdeki insanların kodlara bakıyor olması oldukça heyecanlı :).

Üzerinde çalıştığım proje ise, bellek üzerinde 2kB/4kB kadar boyutlarda olabilen sayfaların dışında bir de büyük sayfalar (huge page) var. Onların boyutları ise 2MB/4MB. Peki neden büyük sayfalara ihtiyaç duyuyoruz? Çünkü sayfalar büyük olduğunda sayfa tabloları da büyük oluyor ve bir süreç için verileri bellekten atma/belleğe getirme miktarı azalıyor. Eğer sayfalar 4MB'tan büyük olursa verimsiz oluyor.

Sistemin swap kullanması gerektiğinde büyük sayfalar normal boyutlu sayfalara parçalanıyor (2kB/4kB) ve o şekilde swap alanına yerleştiriliyor. Sorun şu ki; swap alanından belleğe tekrar geri getirilmek istendiğinde büyük sayfa olarak değil, normal boyutlu sayfalar olarak getiriliyorlar bu durumda eski verim sağlanamıyor, aynı zamanda burada izlenmesi gereken bir algoritmaya da karar verilmeli. Çünkü bir süreç swap kullanıyor diyelim, ve swapte olan bir veriye ihtiyaç duyuldu, sadece tek bir verinin bulunduğu sayfa 2kB, ancak bunun yerine 2MB büyük sayfa getirmek her zaman yararlı olmaz. Burada karar verilmesi gereken noktalar var.

Geçtiğimiz dönem kod ve belge okumak üzerine geçti. Bir tane de yama gönderdim. Sadece okunabilir sayfaları büyük sayfalar şeklinde birleştirmek için. Yamayı burada görebilirsiniz.

Bundan sonraki bir süre ise; "daha önce hiç okuma/yazma isteği almamış, henüz fiziksel belleğe eşlenmemiş, sadece sanalda bulunan, bir süre sonra ilk kez okuma izni aldığında fiziksel belleğe eşlenen sayfalar" var, bunlara zero page deniliyor, bunlar üzerinde çalışacağım. Eğer sayfa içerisinde veri yoksa, ilk okuma isteği aldığında çekirdek bunu sıfırlarla dolu bir sayfa olarak üretiyor. Bunları da büyük sayfalara dahil etmek üzere çalışacağım. Aynı zamanda (emin değilim), Documentation dizininde de belgelendirme yapmam gerekecek. Muhtemelen birkaç işim daha var ancak henüz ben bilmiyorum, danışmanımla işleri bitirdikçe yenisini alma şeklinde ilerliyoruz. Henüz başlamadığımız işlerden de şuna bir ara bakarız şeklinde konuşuyoruz.

Staj sürecinde birkaç Türkçe yazı daha yazacağım (yazmadı) :).

Sending First Patch To Upstream

Last week, I sent first patch to upstream and it was accepted in mm tree :). I am very happy about that. You can see it here.

Subsystem maintainers are very careful and a lot of people review the codes. Out side of staging directory, and before the internship, my first patch is about y2038 project. When I sent patch for y2038, a lot of developers reviewed and suggested something. I have recently seen the patch here: http://lwn.net/Articles/620870/, it was my first experience :).

Todays, I work with linux kernel mm community, this makes me very excited and happy :).  I gained some experiences in this process and learnt how can I be sure with my changes. This is most important case for coding. When I talked with my mentor, every time I reported different thing :) and said "oh this prevents collapsing pages into a thp!". Because I was testing wrong. Finally I could find what was the problem.

For test results, I look /var/log/kern.log, it is very large file so I split it like that: "split -n 5" and look newly created small files and log time stamps is important. To be sure with my changes print out virtual memory address area for my test programs.

/proc/pid/smaps shows whole vmas for the process. pr_info("vm_start = %04lx\n", vma->vm_start); is enough to see begining address of the vma. Sometimes I need to see which process run this function, I print out current->pid. If I know what happened in every step, I find my faults very easy. I have to do something like that, because other processes will log about their huge pages in kern.log and I shouldn't confuse which process logged the results. To examining kern.log was big scale thing for me.

Before sending patch I need to be careful and check something for my patch. Also keeping focus on the issues is important. Working on kernel needs to pay attention more accorrding to other projects which I got experiences with them when I was student.

After this patch, I will work on zero pages and discover new things :).

Happy Coding & Testing Process

After third week, we started coding and made basic things. Our first aim to enable read-only ptes for collapsing. I still look for this issue. Something goes wrong and I can't see what is that.

To test my changes I've prepared test programs. They create pressure on memory and supply to swapped out system. Actually, they are very basic, just make malloc(), read/write operations on memory. memtest and stress are very strong workload programs, but to swapped out something they mix operations which are not correct for me. I should test specific conditions so use my test programs and they will be sophisticated later on.

To get informations about what happened with my changes, I use smem which shows swap usage percentage, pid, ppid with -t -p options and that's enough for me :). For specific process I look /proc/pid/smaps it gives anonhugepages/anonymouspages numbers and swap usage.

To look kernel messages we can use dmesg, but its size is not enough for me :) because I've been testing almost every line of the functions. To increase size of dmesg log, you should should set CONFIG_LOG_BUF_SHIFT in kernel config file. However When I setted it by 27 which means 2^27 bytes, make seems that doesn't accept this number! Probably, the number can be 16 or 17 as suggestion of config, but I'm not sure about that. Then I've looked /var/log/kern.log, and its size enough for me :) I'm sure about test results with it.

do_swap_page() makes swapped in operations afterward khugepaged scans the pages tables that come from do_swap_page(). There is no function call for khugepaged_scan_mm_slot(), it is called per 10000 miliseconds. Its call chain is like that:
khugepaged_scan_mm_slot() -> khugepaged_scan_pmd() -> collapse_huge_page() ->
__collapse_huge_page_isolate()

Today I've realized in khugepaged_scan_pmd(), ptes seem unpresent! but they are swapped in. Then I need to look do_swap_page() again :).