- Direct Memory Access API’yi uygulayan Rust kodu, Linux çekirdek deposuna pull request olarak gönderildi.
- Linux çekirdeğinin orta düzey yöneticilerinden Christoph Hellwig, Rust kodunun Linux çekirdeğine alınmaması gerektiğini söyleyerek bunu reddetti ve anlaşmazlık başladı.
- Anlaşmazlığın boyutu giderek büyürken, Christoph Hellwig Rust’ı kanser hücresine benzetti.
- Asahi Linux’un genel sorumlusu Hector Martin, bu kanser hücresi benzetmesine tepki göstererek sosyal medyada Linus Torvalds’ı da işin içine çekip çok sert eleştiriler yöneltti.
- Linus Torvalds, Hector Martin’e "Sorun sensin" diyerek "sosyal medyada kamuoyu yönlendirmesi (brigading) yapma" uyarısında bulundu.
- Şu anda Hector Martin, Apple Arm uyumlu donanımı destekleyen upstream Linux kodu yöneticiliğinden ayrılmayı talep ediyor.
28 yorum
Özet metin yalnızca yaşanan olaylardan bahsediyor; ancak asıl yazının sonunda (Korece) olayı daha iyi anlamak için iki ek arka plan bilgisi daha yer alıyor.
Projenin tek bir dille yönetilmesinin iyi olduğunu düşünüyorum, ama bundan bağımsız olarak bunu çalışma arkadaşlarına kabul ettirme biçimi gerçekten berbat.
İnsanları güç kullanarak diz çöktürmek adaletsizliktir.
Bu PR e-posta dizisi:
https://lwn.net/ml/all/…
Görünen o ki DMA implementasyonu değiştirilmemiş, DMA API’sine de doğrudan dokunulmamış; Rust’tan DMA API’sine erişilebilmesi için FFI binding’leri yazan bir PR söz konusu.
Böyle bir PR ise "No rust code in kernel/dma, please." gibi kısa bir yanıtla reddedilmiş, https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
Peki o zaman nasıl yapılması gerektiği sorulunca da "Keep the wrappers in your code instead of making life painful for others." deniyor. https://lwn.net/ml/all/20250108151858.GB24499@lst.de/
(Söyleneni yaptıkları da doğru. PR, kernel/dma’yı değil, rust/kernel alt ağacını değiştiriyor.)
Elbette FFI binding’leri eklendiğinde DMA API değiştiğinde Rust FFI binding’lerinin de güncellenmesi gerekeceği gibi bir yük oluşacaktır,
ama buna Rust tarafıyla ilgilenenlerin kendilerinin bakacağını söylemiş olmalarına rağmen, ilgili ağacın sorumlusu olmayan birinin bu tavırla karşı çıkmasının doğru olup olmadığından pek emin değilim.
(Christoph Hellwig, kernel/dma maintainer’ıdır: https://docs.kernel.org/process/maintainers.html#dma-mapping-helpers)
Bu yüzden Hector Martin galiba Linus’u dizinin içine çekmiş:
https://lwn.net/ml/all/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/
Ama hemen önceki dizide geçen konuşma biraz ilginç,
mesele şu: 'API’de breaking change oluştuğunda Rust ekibi buna hızlıca yanıt vermezse build bozulur ve Linus da PR’ı kabul etmez.'
Ben buna, breaking change yaratan modülle başka bir modül arasındaki sorun olarak bakınca, Rust bulunan tarafın daha iyi durumda olduğunu düşünüyorum.
x modülü bir breaking change yaptı ve y modülü buna hızlıca yanıt veremedi diyelim,
Linux çekirdeğinde Rust'ın
unsafekullandığı kısımlar çoğunlukla C ile wrapping yapılan bölümlerdir.Bunun dışında belleğin doğrudan ele alınması gereken donanım kontrolü bölümleri de var, ancak bunlar çok azdır.
Rust'ın uygulanacağı alan sürücü geliştirmedir. Bellek yönetimi ya da block layer gibi çekirdeğin kendisine dokunmak ne gerekir ne de mümkündür.
Çekirdeğin kendi kodundan çok daha fazla kod sürücü kodudur. Ve sorunların ortaya çıktığı noktalar da çoğunlukla sürücü kodlarıdır.
Bence sürücü geliştirme kısmının C'den daha yüksek bellek güvenliği ve daha iyi güvenlik sunan bir dille geliştirilmesi doğru olur.
Bunun Rust mı, Zig mi yoksa başka bir şey mi olacağını bilmiyorum.
Rust'ın genel uygulama geliştirmek için gereğinden fazla karmaşık olduğu ve C geliştiricilerinin hızlıca öğrenmesi için de zor olduğu görüşüne ben de katılıyorum.
Yine de hangi dil olursa olsun, en azından sürücü geliştirmenin modern bir dile geçmesini umuyorum.
Ben önceki şirketimde birkaç bin satırı bile olmayan bir sürücüyü geliştirip kararlı hale getirmek için yaklaşık 7 yıl harcadım; bunu tamamen basitleştirmek mümkün değil ama kabaca 3 yılı sadece debugging ile geçmiş gibi görünüyor.
Bunların çoğu bellekle ilgili hatalardı. Deadlock gibi mantıksal hatalar ise azınlıktaydı.
Büyük projeleri kendi dilinin deneme sahası olarak kullanmak pek iyi görünmüyor.
İşler ters giderse eskiden olduğu gibi fork atmaya dönmek gerekebilir.
Cihazların genelini kapsayan bir çekirdekte Rust kullansan da,
unsafeyazmaya başlayınca sonuçta okunması zor, sorun çıkaran kodlara dönüştüğü düşüncesinden öteye gidemiyorum.Kaldı ki bu, 0.91 0.92 0.99 0.991 gibi ana sürümü bile olmayan bir proje de değil; neden zaten sorunsuz çalışan kısımları port ettiklerini anlamıyorum.
Büyük bir bug çıkıp da onu düzeltirken güvenli hale getirdik de denmiyor.
Söz konusu PR bir port değil. Mevcut DMA API'sini Rust tabanlı, sıfırdan yazılan modüllerde de kullanılabilir hale getirmek için Rust tarafında FFI binding'leri ekleyen bir PR. DMA sorumlusu da bunu engelledi.
Makalede alıntılanan asıl metnin olmaması üzücü. Merak edip asıl metni bulup okudum; ben de tam olarak kavramış olmayabilirim ama olayı yalnızca asıl metindeki gibi anlatmak için arka planda epey fazla şey var gibi görünüyor.
Yazının başlığı, özgün adıyla değiştirildi.
İlgilendiğiniz için teşekkürler
Büyük bir C kod tabanına Rust eklemek, sanıldığı kadar eğlenceli değilmiş. Bellek güvenliğini artırdığı söyleniyor ama sonuçta
unsafealanı yine büyüdüğü için pratikte etkisi çok büyük olmuyor.... Bu da Rust kullanım alanının genişlemesinin ötesinde pek bir anlam taşımıyor.... Dolayısıyla mevcut C geliştiricilerinin buna tepki göstermesi doğal bir süreç gibi görünüyor. Gerçekten en baştan Rust ile başlayan çekirdek projelerine odaklanmak daha iyi olabilir gibi görünüyor.Doğrusu, metnin kalitesi beklediğimden daha iyiymiş; keyifle okudum.
Torvalds’ın söylediği “sorun sensin” ifadesinin vermek istediği mesaj, Rust’un benimsenmesinden bağımsız olarak teknik sorunların çözümünün SNS olamayacağı yönündeydi; ancak yalnızca bu özete bakılırsa yanlış anlaşılmaya açık görünüyor.
Héctor Martin için bu, kaçınılmaz bir tercihti.
Linux’un orta kademe yöneticilerinin tamamı C uzmanlarıyla doluyken, sayıca az olan Rust geliştiricilerinin görüşlerini dikkate almaları beklenebilir miydi ki.
https://youtu.be/opTJH76wJxs?si=WHR0_1uPpSlpDTHr bunun bir tartışmaya dönüşme sürecini gösteriyor.
Torvalds da Rust'a izin vermiyor muydu?
Torvalds bu tartışmada Rust hakkında tek kelime etmedi.
Teknik görüş ayrılıkları olduğunda, tartışma teknik gerekçeler üzerinden yürütülmeli;
sosyal medyada kamuoyu oluşturarak anlaşmazlığı bitirmeye çalışmayın demek istiyor.
Madem o kadar iyisiniz, çekirdeği fork'layıp baştan sona Rust ile yazın. Kansere benzer şekilde sinsice içeri sızmaya çalışmayın. Böyle düşünen çok kişi var gibi görünüyor.
Söz konusu kod, Rust’ta yazmayı kolaylaştırmak için
kernel/dmatarafını kurcalayan bir kod olsaydı neyse derdim,kernel/dmayı saran bir FFI katmanınırust/kernel/dmaya ekleyen bir koddu. Orijinal koda dokunulmadı.Aslında meselenin özü, Rust ile hazırlanmış resmi DMA FFI’si yanlış kullanılıp sonra bana soru gelmesinden hoşlanmıyorum. düzeyinde bir şeydi... Buna rağmen de, her sürücü tarafı kendi FFI’sini kendisi yapsın, dedi; yani başı sonu tutmayan bir laf etmiş oldu.
Bu Redox. Henüz desteklemediği kısımlar olduğu için Linux'a gidiyorlardır muhtemelen...
https://vt.social/@lina/113064510447670892
Yazdıklarınız tamamen Helwig’in ifadelerinin birebir tekrarı gibi görünüyor, ancak bu görüşlerin çoğunluğu temsil ettiğini söyleyip söyleyemeyeceğimizden emin değilim.
Merhaba. Güzel yazıyı paylaştığınız için teşekkür ederim. Keyifle okudum.
Ancak orijinal metni ve orijinal başlığı kontrol ettiğimde beni biraz endişelendiren bir nokta gördüm; bu yüzden yorum bırakmak istedim.
https://news.hada.io/guidelines
> Temel olarak yazının orijinal başlığını ekleyin ya da başlığı Koreceye çevirerek paylaşın.
şeklinde bir öneri var. Ayrıca ilgili yazının içeriğini okuduğumda, "Linux çekirdeğinde Rust tartışması yeniden alevleniyor." yerine "Linus Torvalds: 'Sorun sensin'" başlığının, orijinal başlıktan da fazla, yazının içeriği hakkında yanlış anlamalara yol açabileceğini düşünüyorum.
Özeti ve yazıyı tanıttığınız için tekrar teşekkür ederim. İyi günler dilerim.
Süper
Dikkate alacağım.
'm 'b İyi günler dilerim! Sayenizde güzel bir yazı okudum, teşekkür ederim. (__ )
Daha doğru bir açıklama için başlığa kendi alt başlığımı eklemek benim alışkanlığımdı; ancak başlık başka birine uygun düşmemiş ve böyle bir kural olduğunu da bilmiyormuşum. Bundan sonra metni özgün haliyle paylaşacağım.
Orijinal başlık, konunun ne hakkında olduğunu hemen anlamayı sağlarken, değiştirdiğiniz başlık ise yanlışlıkla clickbait olduğu yönünde bir algı yaratabilecek gibi görünüyor. Bu benim kişisel görüşüm.
Görüşünüz için teşekkür ederim.
Linus’un açıklamasını en önemli nokta olarak düşündüğüm için başlığa taşımıştım, ama anlaşılan bunu epey çarpıtmışım.
Buna kesinlikle dikkat edeceğim.