Linux çekirdeği geliştirmek için Rust diline gelen yeni özellikler

• Rust for Linux projesi, çekirdek geliştirme için gerekli temel dil özelliklerini ilerletirken Rust dilinin kendi gelişimine de katkı sağlıyor
• Üç ana başlık öne çıkıyor: Field Projection, In-place Initialization ve Arbitrary Self Types
• Bu özellikler, akıllı işaretçiler, sabitlenmiş bellek (Pin), RCU gibi çekirdeğe özgü yapıları Rust’ta daha doğal biçimde ifade etmeyi sağlıyor
• Rust ekibi tasarım kararlılığına önem verdiği için geliştirme hızı yavaş ilerliyor; ancak Linux çekirdeği gibi net bir hedef odaklanmayı artırıyor
• Bunlar çekirdek dışındaki Rust ekosistemine de etki edecek değişiklikler; özellikle akıllı işaretçi kullanımı ve kod sadeleştirme açısından büyük fayda sağlaması bekleniyor

---

Rust dilindeki iyileştirmeler ve Linux çekirdeğinin rolü

• Rust diline yeni özellik eklenmesinin yavaş olmasının nedeni, kötü bir tasarımın dile kalıcı biçimde yerleşmesini önlemeye yönelik temkinlilik ve "dikkatin hizalanması (alignment in attention)" sorunu
  • Rust projesi gönüllüler tarafından yürütüldüğü için, belirli bir özelliğe odaklanan kimse yoksa geliştirme gecikebiliyor
• Rust for Linux projesi birçok kişinin heyecan duyduğu bir konu olduğundan, çekirdeğin ihtiyaç duyduğu birkaç kritik özelliğe çabayı yoğunlaştırmaya yardımcı oluyor
• Rust dil ekibinin eş lideri Tyler Mandry, Kangrejos 2025’te Rust’ın yaklaşan dil özelliklerini tanıtırken Linux çekirdeği projesinin Rust’ın gelişiminde katalizör görevi gördüğünü belirtti
  • Başlıca özellikler: Field Projection, In-place Initialization, Arbitrary Self Types
  • Çekirdek geliştirme, gerçek kullanım senaryolarını ve teknik gereksinimleri açık biçimde ortaya koyarak Rust’ın dil tasarım yönünün somutlaşmasına katkı sağladı
  • En yüksek öncelik, çekirdek binding’lerinde halihazırda kullanılan unstable özelliklerin standartlaştırılması

Field Projection

• Bir struct işaretçisinden belirli bir alanın işaretçisini çıkarmaya yarayan bu özellik, C’deki &(r->field) ifadesini Rust’ta genelleştirme girişimi
• Daha önce bu yalnızca referanslar (&) ve işaretçiler (*mut) için mümkündü; kullanıcı tanımlı akıllı işaretçilerde ise sınırlamalar vardı
• Rust for Linux bunu genişleterek, tüm işaretçi türlerinde aynı sözdizimiyle alan erişimini mümkün kılmayı hedefliyor
• Özellikle Pin türüyle (taşınamayan struct’lar) çalışırken, alan projeksiyonu sırasında otomatik olarak Pin<&mut Field> veya &mut Field dönüşümü yapılacak şekilde tasarlanıyor
• Bu özellik hayata geçtiğinde, RCU (Read-Copy-Update) deseninin Rust’ta güvenli biçimde desteklenmesi mümkün olacak; böylece kilit (lock) kullanmadan yüksek performanslı veri erişimi sağlanabilecek
• Konu şu anda GitHub’daki tracking issue üzerinde tartışılıyor ve Debian 14’ten (2027) önce kararlı hale gelmesi hedefleniyor

Arbitrary Self Types

• Akıllı işaretçileri kabul eden metod tanımlarını mümkün kılan bir özellik
• Önceden yalnızca fn method(&self) biçimi desteklenirken, artık fn method(self: Pin<&mut MyStruct>) gibi tanımlar da mümkün oluyor
• Çekirdekte Arc, Pin, Mutex gibi çeşitli işaretçi sarmalayıcıları kullanıldığı için bu özellik kritik önem taşıyor
• Uygulama sürecinde Deref trait’iyle çakışma sorunu vardı; bu, yeni Receiver trait’i eklenerek çözülmeye çalışılıyor
• Receiver, bir işaretçinin arbitrary self type olarak kullanılabileceğini açıkça belirtme görevini üstleniyor
• Çekirdek geliştirmede bu sayede işaretçi zinciri çağrıları daha sade tutulabilecek
• Ding, Crater aracını kullanarak mevcut Rust paketleriyle uyumluluğu doğruluyor ve bunun 1 yıl içinde kararlı hale gelebileceğini söylüyor

In-place Initialization

• Çekirdekte kullanılan pin_init!() makrosunu dil düzeyinde desteklemeyi amaçlayan bir özellik
• Bir nesneyi oluşturduktan sonra taşımadan, doğrudan bellekte başlatmayı sağlar; bu da Pin struct’ları, Future ve dyn trait’leri için kullanışlıdır
• Üç farklı öneri paralel biçimde tartışılıyor
  • init anahtar sözcüğü yaklaşımı: En az sözdizimi eklemesiyle mevcut PinInit trait’inden yararlanma
  • &out referans yaklaşımı: C’deki out pointer gibi yalnızca yazılabilir referans ekleyerek alan düzeyinde başlatmayı destekleme
  • C++ tarzı optimizasyon yaklaşımı: Anında heap’e taşınacak nesneleri en baştan doğrudan heap üzerinde oluşturma
• Son aşamada hem PinInit hem de out-reference yaklaşımının deneysel olarak sınanması ve gerçek kullanışlılığın doğrulanması planlanıyor
• Bu özellik devreye girerse, yalnızca çekirdeğe değil genel olarak asenkron Rust kodlarının yapısının sadeleşmesine de katkı sağlayacak

Rust for Linux’un Rust üzerindeki etkisi

• Linux çekirdeği, Rust dilinin gelişiminde gerçekçi bir test ortamı işlevi görüyor
• Üç özelliğin tamamı akıllı işaretçiler, sabitlenmiş bellek ve eşzamanlılık yapıları gibi çekirdeğe özgü ihtiyaçlardan doğmuş olsa da,
  sonuçta genel Rust geliştiricileri de bunlardan fayda sağlayacak
• Bu değişiklikler, çekirdek ile dil geliştirme arasındaki olumlu geri besleme döngüsünü gösteren bir örnek olarak değerlendiriliyor

[GN⁺]

Hacker News görüşleri

• Rust'ın lightweight clones özelliğine dair RFC belgesini okuyup anlamam biraz zaman aldı. Başta bu özellik oldukça ilginç gelmişti, ama sonunda Rust'ın öğrenmesi karmaşık bir dil olduğu hissi bende yine güçlendi. Rust ya da C++'ı düzgün öğrenmemiş biri olarak bana, modern C++'ın tüm kavram ve özelliklerinin Haskell unsurlarıyla birleşmiş hali gibi geliyor. Buna rağmen insanların Rust ile çok faydalı şeyler üretmesini görünce ortada gerçekten doğru bir şeyler varmış hissi oluşuyor. O yüzden yakında Rust'ı yeniden ciddi biçimde denemeyi düşünüyorum. İlgili RFC bağlantısı

  • Benim deneyimime göre C++, Rust'tan çok daha karmaşık. Örneğin sadece başlatmanın 8 yolu var, değer kategorilerinde xvalue gibi 5 tür var, biçimlendirme ve adlandırma kuralları tutarlı değil, rule of 5 var, istisna yönetimi var, move assignment yaparken sürekli this != other kontrolü gerekiyor, perfect forwarding, SFINAE, trait karşılığı çözümler gibi sayısız karmaşıklık var. C++'ı düzgün kullanmak için standardın üzerine eklenen, güvenli ve hızlı kod yazmayı sağlayan teamülleri de öğrenmek gerekiyor; istisna yönetimi gibi yaklaşımlar da sık sık birbiriyle çakışıyor ya da ideal olmayan yollar seçmeye zorluyor

  • Rust topluluğunda bu lightweight clones önerisine karşı hava giderek olumsuzlaşıyor. Sebebi fazla karmaşık bulunması. Tasarım yönüne dair resmi Rust belgesinde de en büyük engel olarak karmaşıklık gösteriliyor. Rust'a önerilen her özelliğin mutlaka çok basit olması gerekmiyor ama lightweight clone zaten bugün yapılabilen bir şeyi biraz daha kolaylaştırıyor; insanlar bunu kolayca anlayamıyorsa bu da bir sorun

  • Rust uzaktan bakınca çok kapsamlı görünüyor ama gerçekten kod yazınca insan hızla alışıyor. Mesela ben başta lifetime kavramını hiç anlayamadığım için sadece Rc<> ile kod yazıyordum. Temelleri öğrendikten sonra lifetime konusuna geri dönünce çok daha kolay geldi. Aslında çoğu kullanıcının lightweight clones gibi özelliklerle işi bile olmaz

  • C'ye kıyasla çok karmaşık ama C++'a göre çok daha sade bir dil. Kodu anlamak için sürekli belge ya da referans kurcalamayı gerektirmiyor. Rust, "o kadar karmaşık değil ki insanın başını ağrıtsın, o kadar basit de değil ki kod gereksiz yere karmaşıklaşsın" denebilecek çok iyi bir noktada duruyor. Üstelik varsayılan olarak kodun correctness sağlamasına yardımcı oluyor

  • Rust'ın karmaşıklığı, C++'taki gibi yanlış kullanımı kolay bir karmaşıklık değil. Üstelik clippy kullanınca daha idiomatic koda otomatik dönüşüm öneriyor; bu yüzden lightweight clones gibi yeni özellikleri doğrudan bilmiyor olsanız bile size önerilebiliyor. Bunların çoğu clippy'nin --fix seçeneğiyle de kolayca uygulanabiliyor. Bu nokta C++'tan belirleyici biçimde farklı; C++'ta kullanılmayan özellikler birikiyor ya da insanlar dili gereğinden karmaşık kullanıyor ve bu da sürekli ek karmaşıklık üretiyor

• Rust for Linux projesinin Rust'a çok fayda sağladığı söylenince merakımdan kernel ağacında *.rs dosyalarını aradım. Gördüğüm kadarıyla rust klasörü altında bir API uyumluluk katmanı var ve kernel ağacında da mevcut sürücülerin basit yeniden yazımları olan birkaç proof of concept sürücü bulunuyor (tamamlanmamış Nvidia sürücüsü hariç); fiilen kullanılan bir şey yok gibi görünüyor. Android binder'ın Rust ile yeniden yazımı da sanki neredeyse öylece bekliyor gibi geldi. Genel izlenimim bunun sadece sevimli bir deney projesi olduğu yönünde; dünyanın en önemli yazılımının kaynak ağacında böyle bir dil ortak geliştirme deneyine gerçekten gerek var mı diye düşünüyorum. Belki bunu Redox gibi daha deneysel bir işletim sisteminde yapmak daha uygun olurdu

  • Apple silicon için GPU sürücüsü Rust ile yazıldı ve yazarı, bunu C ile geliştirse çok daha zor olacağını söylüyor. Henüz upstream'e girmedi ama "karmaşık bir kernel sürücüsünü sıfırdan geliştirirken race condition, memory leak, use-after-free gibi her tür sorun ortaya çıkabiliyor; Rust ile yazınca ise bunlar neredeyse hiç yaşanmadı ve kararlı çalıştı. Güvenlik özellikleri sayesinde sürücünün thread-safe ve memory-safe olduğuna gerçekten güvenebildim, ayrıca tasarım da doğal biçimde daha iyi bir yöne akıyor. Rust'ın büyüsü bu" diyor. Yazarın deneyim yazısı Ayrıca bunun gibi deneylerin kernel ağacında yapılıp yapılamayacağı sorusuna Torvalds'ın karşı çıkmadığı belirtiliyor

  • "Android binder'ın Rust ile yeniden yazımı sadece bekliyor" görüşü doğru değil. Bu proje şu anda C uygulamasının yerini tamamen almayı hedefliyor. İlgili haber Apple'ın M serisi donanımları için önemli sürücüler de Rust ile yazıldı; bunlar basit yeniden yazım ya da proof of concept değil

  • Karmaşık sürücüler yazabilmek için önce arayüz katmanına ihtiyaç var. RfL projesi de bu tür altyapı katmanlarını upstream'e eklemekle uğraşıyor; bu temel oluşmadan karmaşık sürücüler yazılamaz. Red Hat nova üzerinde, Asahi Apple GPU üzerinde, Collabora ise ARM Mali için çalışıyor. Eğer üç GPU sürücüsü de karmaşık sürücü sayılmıyorsa, o zaman karmaşık sürücüye ne deneceğini merak ederim

  • Binder'ın Rust ile yeniden yazımının sadece beklediği iddiasına karşılık, Linus ağacındaki commit mesajları bunun oldukça olgun bir durumda olduğunu gösteriyor. Rust binder, Android Open Source Project'in tüm binder testlerini geçiyor ve çeşitli uygulamalar ile özellikler belirgin bir sorun olmadan çalışıyor. Cuttlefish emülatöründe ve Pixel 6 Pro'da açılış ve uygulama çalıştırmada sorun yok. Mevcut işlevler de C binder ile aynı; sadece bazı hata ayıklama özellikleri eksik ve onların da yakında ekleneceği söyleniyor. Ayrıca Rust for Linux projesi başlangıçta kernel ağacı dışında başlamış olsa da, gerçek entegrasyonu denemek için sonunda ağacın içinde deneme yapmak gerekiyor

  • Bu projenin amacı dil geliştirme için ortak bir deney yapmak değil; Linux kernel geliştirmede Rust kullanmak. Çekirdek geliştiriciler Rust kullanmak istediği için bu projeyi kendileri başlattı. Söz konusu yazılım çok önemli olduğu için süreç dikkatli ilerliyor ve temelin oturması zaman alıyor. Rust'ın bu süreçten yan fayda sağlaması ise ekstra bir kazanım

• Makaledeki <i>field projection ile ilgili bölümde, artık tüm struct alanlarının yapısal olarak pin'lenmiş kabul edilip Pin<&mut Field> gibi türlerin her zaman üretileceğine karar verildiği</i> kısmını görünce bunu daha önce kaçırdığımı fark ettim. Teknik olarak karmaşık bir konu ama bu kararın, pek çok tartışmayı tıkayan sorunu çözmesi sevindirici

• <i>Nihai tasarımın, C++'tan esinlenerek bir değeri heap üzerinde tahsis etmek için yeni bir değer oluşturulup hemen taşındığında, onun en baştan heap üzerinde oluşturulmasını sağlayan beklenen bir optimizasyon tekniği</i> üzerine tartışıldığını görüyorum. Buradaki 'optimizasyon' adı yanıltıcı olabileceği için ismin değiştirilmesi de konuşuluyor

  • Sorunun karmaşıklığını tam kavramıyor olabilirim ama uygun bir calling convention belirlenirse bunun kolay çözülebileceğini düşünüyorum. Struct boyutu x'ten büyükse ya da bir marker type varsa, caller bir outref tamponu verir ve callee struct'ı doğrudan o tampona yazar. Böylece sıradan kod yazarken bile yinelenen heap tahsisleri engellenebilir, başka durumlarda da gereksiz kopyalar azalır. Bu konuya zaten çok emek harcandığı için, önerilen çözümlerin neden daha kullanışsız göründüğünü merak ediyorum

  • Bunun iç optimizasyon olarak ele alınması yerine new benzeri bir işlevle açıkça sunulmasının herkes için daha sezgisel olacağını düşünüyorum

  • C++'ta bu tür semantics için elision deniyor

  • "coalesced heap construction" ya da "coalesced heap allocation" gibi adlar önerilebilir

• Rust'ın çeşitli özelliklerinden söz edildiğinde her seferinde "yeter ki tokio'yu kernela sokmayalım" diye şaka yapasım geliyor. Eğer Rust yeterince gelişir ve direct composition renderer ortaya çıkarsa, tüm kernel üzerinde çalışan uygulamaların mümkün olduğu bir dünya da epey ilginç olabilir

  • Kernel içinde bir async runtime uygulamak aslında gayet trivial. Hatta kernel'in workqueue yapısı zaten başlı başına bir runtime

  • Bu şaka değilse, kernel kodunun Rust'la (ve C ile) nasıl yazıldığına dair temel bir yanlış anlama var demektir. Kernel'de kod yazarken, C stdlib gibi Rust da no_std ile çalışır; cargo ya da crates de kullanılamaz. Tokio kullanmak isterseniz neredeyse yarısını yeniden yazıp socket gibi OS ile etkileşen tüm bölümleri kernel tarzıyla değiştirmeniz gerekir

• Linux'a giren bu yeni Rust özelliklerinin sadece kernel için değil, Rust dili genelinde geniş ölçekte faydalı ilk özellikler olduğunu düşünüyorum. Kernel merkezli özellik geliştirmenin başka dil/kütüphane geliştirmelerini bir miktar geri planda bırakmış olduğu izlenimine kapıldım

  • Bildiğim kadarıyla systems programming, Rust'ın öncelikli kullanım alanı. Özellikle OS, embedded ya da karmaşık C tabanlı sistemlerde birlikte çalışabilirlik kritik önem taşıyor. Bu özellikler de aslında kernel'e özel değil, gerçek dünyadaki sistem programlama için gerekli genel araçlar gibi görünüyor

  • Kernel/firmware geliştirmeye yönelik ilerleme birçok yerde yaşanıyor ama bunlar herkesin sürekli takip ettiği gündem maddeleri olmuyor. Philipp özellikle bu alanda önemli değişimler yaratıyor

  • Rust'ın ana rolü low level sistem programlama. Diğer alanlarda userspace için derlenen managed diller çoğu zaman çok daha iyi seçenekler. Self, Inferno ya da Android mimarisi gibi yapılarda, bu tür low level C tarzı özelliklere odaklanmakta bir sorun görmüyorum

• Bu özellikler sadece kernel için değil, başka alanlara da fayda sağlayacak kadar güzel görünüyor (özellikle generalized projections). Linux'un Rust dilinin gelişimini yönlendirmesi beni çok memnun ediyor

• LLM kullanarak C kodunu otomatik biçimde Rust'a dönüştüren araştırma ya da araçlar olup olmadığını merak ediyorum. Bir LLM'e chat, USB, I2C, GPU driver gibi Rust kodları yazdırıp derletmek/test ettirmek mümkün olur mu, ya da sqlite, apache, nginx gibi "daha küçük" projelerde bunu denemek mantıklı mı diye düşünüyorum

  • LLM tabanlı olmayan tarafta gerçek örneği bulunan c2rust projesi var. LLM'ler doğaları gereği yaklaşık sonuç üretir; bu yüzden işi tam doğru yapamazlar ve çok fazla subtle bug üretirler. Formal methods gibi şeylerle birleştirilmedikçe pratik olmaları zor. Yalnızca birim testleriyle yakalanmayacak pek çok sorun da var. Ayrıca "daha küçük" diye verilen örnekler de aslında yeterince küçük değil. Gerçek kullanım örnekleri incelenebilir

  • DARPA da bu tür araştırmalarla ilgilenip fon sağladı, ama henüz somut sonuç çıkmış değil

[ahwjdekf]

Dogmatizmde hizalama (alignment in dogmatism)