Rust-ban írna GPU driver-t a Linux kernelhez Apple M1/M2 hacker

Kernel

Asahi Lina az Asahi Linux projekt körül tevékenykedik. Az Asahi Linux projekt célja egyebek mellett a Linux kernel portolása az Apple M1/M2 gépekre. Asahi Lina most a Linux kernelfejlesztői közösség véleményét kéri a következőben: Rust-ban írna GPU driver-t az Apple M1/M2 chipjeihez

   

A fejlesztő levele és a rá érkezett válaszok itt olvashatók. Reddit szál itt.

( bennyh | 2022. 08. 12., p – 14:28 )

Na az több szempontból is érdekes lenne. A Rust-nak is jól jönne.

( Polesz v | 2022. 08. 12., p – 14:47 )

Felőlem Cobolban is írhatja ha ért hozzá! :)

Így van. Ebben a kérdésben nem az internettel kell egyeztetni. Ő a fejlesztő, írja, amiben akarja. Én a C híve lennék, de ha ő Rustban akarja, ahhoz ért jobban, azzal dolgozna szívesebben, akkor mit lehet tenni.

A másik, hogy nem érdekel miben írja, csak legyen kész. Az M1-nél már 2 éve húzódik, hogy nincs linuxos GPU driver, csak szoftverrender LLVM. És itt nem akarok a fejlesztővel szigorú lenni, mert abszolúte nonprofit csinálja, nem nekünk dolgozik, a felhasználók köszönhetik meg az eddigi munkáját is. Igazából ez az Apple sara, hogy nem teszi legalább a fejlesztőknek hozzáférhetővé a driverkódot, GPU specifikációkat, még akkor se, titoktartás mellett se, ha ingyen dolgoznának neki.

Ami inkább zavar, az az animés, rózsaszín borzalom, ami fejvesztéssel járó közízlés-sértés. Ha nőről van szó, akkor is elég nehéz neki marginálisan elnézni, de ha férfi van a nick mögött, akkor ultra gáz.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

"Férfi" van mögötte, pontosabban Hector csinálja ezt is csak vtuber puppet avatarral, hangtorzító modullal. Eredetileg április 1.-én mint tréfa indult az első GPU-s stream ezzel a vtuber formátummal, végül a GPU-s munkához megmaradt ez. A nem GPU-s részeket normál módon streameli. Egyébként pedig egyetértek, ízléstelen és degenerált ez az egész.

Felőlem

Felőled lehet, csak Torvalds felől nem. Ha a cél a mainline kernelbe kerülés, akkor eléggé szűk a mozgástered. A Rust egy olyan nyelv, amit lehet, hogy Torvalds és az alrendszer karbantartók sem basznak majd ki, mint macskát szarni:


> I realize it's the early days of Rust on Linux and this is an ambitious
> challenge, but I'm willing to learn and the driver will take some time
> to stabilize to the point of being upstreamable either way (in
> particular the UAPI), so writing it in Rust feels like less of a gamble
> at this point than it used to be, given that it sounds like Rust will be
> merged in the next few kernel cycles at the latest.

[...]

In other words, we would love to see Rust used everywhere (of course)
but we have to be mindful about where/how we introduce it (we are not
even in mainline yet), and be as much in agreement as possible with
maintainers where it may affect them.

[...]

 

trey @ gépház

Ez még egy régebbi írás, azóta a Rust támogatott a kernelben. Ennek ellenére egyetértek, rizikós Rustban írni, új dolog még a kernelben, meg kevesebben értenek hozzá. Ha C-ben van írva, akkor többen be tudnak segíteni a kódba, bugokat javítva, optimalizációkkal, meg ha a fejlesztőnek nincs már rá ideje, más könnyebben veszi át a helyét, lesz utánpótlás, aki karban tartja a kódot. Mégis csak a C a natív nyelve nem csak a Linux kernelnek, de az egész unixos, unixlike világnak. Értem, hogy a Rust modern, fasza, biztonságosabb, az orrunkat is tisztíccsa, de nem mindig muszáj a kereket újra feltalálni. Főleg kerneldriver az a műfaj, amiben nem ildomos újra feltalálni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( popacsek | 2022. 08. 12., p – 14:57 )

Rövid rust-tal való ismerkedés után nekem az a véleményem - vagy inkább csak érzésem, mivel nem mélyedtem bele - alakult ki, hogy a rust egy tévút.

Egy bonyolult programozási nyelv helyett ahol nehézkes betartani a szabályrendszert (maga a rust lib-je is tele van olyan direktívákkal, utasításokkal, amik kikapcsolják a rust compiler követelményeit), jobbnak tartanám azt az utat, amikor a nyelv egyszerűbb, de a környezet elég intelligens ahhoz, hogy rámutasson az elkövetett hibákra. Gondolok itt arra, hogy mondjuk meg tudná találni a fordító/ellenőrző tool azokat a pontokat, ahol túlírom a memóriát, vagy nem szabadítom fel, stb. Nyilván nagyon nehéz - ha nem lehetetlen - egy ilyen ellenőrző eszközt tökéletesre megírni, mégis inkább valami ilyesmibe fektetném bele az energiát.

Szokni kell, az biztos, és abban is igazad van, intelligensebb fordító sokmindent kiszúr már most is, de van igény biztonságosabb, GC nélküli programnyelvre. Én primszám keresőt írtam kis multitaszkkal. Kicsit vért kellett izzadni, de úgy éreztem, idővel bele lehetne jönni és a picike binaris is bejött mindenféle futtatókörnyezet nélkül Java után.

Azt nem tudom, hogy a csomagok mennyire stabilak, biztonságosak és használhatók hosszú távon.

Ezt elhisszük neked, de mikor digitális jobbágyok ezreire-milióira van szükség, nem biztos, hogy mindnek ilyen elvszerű a munkája.

Ha le tud tenni az illető egy működő GPU drivert rust-ban (minél kevesebb unsafe-el :D), az azt jelenti, más is tud majd, ha meg nem, akkor passz.

Nekem az a bajom vele, hogy elég olvashatatlan. Egy C-s kódba bele tudok nézni és látom hogy mit csinál, ugyanez igaz a C++-ra is. A Rust-ot meg meg kellene ehhez tanulni, de őszintén szólva nem nagyon látom értelmét az N+1. hardverközeli, de azért magasszintű nyelv megtanulásának.

Én C++ programozóból lettem python fejlesztő, utána találkoztam a Rusttal, és nekem a kifejezetten olvashatónak, és logikusnak tűnik - mondjuk az is igaz, hogy nagyobb projektet még nem láttam benne. :DDD

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

( carlcolt | 2022. 08. 13., szo – 04:49 )

Jaj ne.

Nem csuszott vele eleget, meg Rusttal is akar ilyen teruleten bohockodni.

( emberk | 2022. 08. 14., v – 08:04 )

Az csak a nyelv. Lényegtelen. Egyik nyelveben ez a kényemelsebnb gyorsabb másikban az. Ettől még nem veszek aplet az tuti. Majd ha jó lesz az ér érték aránya. 

Szokott lenni open source vs. proprietary felmérés. Az open source oldalon a Linux kernel szokott szerepelni. Amikor utoljára néztem, az open source nyert.

Mire alapozod a kijelentésed? Mégha nincs is köze a kommentednek ahhoz, mihez írtam?

A Linux kernel hozzájárulóknak meg kell felelniük a coding standards-ban/coding style-ban rögzítetteknek, ha mainline-ba akarnak kerülni. Ha ezt nem sikerül megugrani, akkor nem lesz merge.

Nem hogy a nyelv nem mindegy, még az sem, hogy milyen a behúzás a kódban.

https://www.kernel.org/doc/html/v4.10/process/coding-style.html

trey @ gépház

Azért humoros a rozsdásítók vergődése ezzel párhuzamba állítva. Nem a Rusttal van a probléma, hanem azzal, hogy fragmentálja a projectet. Ha egy adott nyelv van használva, egy adott csomag maintainerének a kisesése nem okoz gondot. De mi van akkor, ha kiesik a fejlesztő és nincs helyette senki aki az adott nyelvhez hozzá tudna szagolni?

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Mindegy, hogy szerinted függ-e vagy sem. Egy meglevő projekthez akarsz hozzájárulni, ahol megvannak a hozzájárulási szabályok. Olvashatóság nem utolsó szempont egy ekkora projektnél. Egy contributor-nak itt annyi a választási lehetősége, hogy betartja a szabályokat vagy nem.

trey @ gépház

Hát mintha most lett volna valami magyar mókus a hup-on, aki 80k LOC-t gereblyézett rendbe, mert annyira fosul volt megírva, hogy senki nem mert már hozzányúlni.

A másik meg ami így hirtelen eszembe jut az az, hogy kb csak GCC-vel fordul a kód, nem bármivel, és ott is csak ilyen-olyan hack-eket bekapcsolva.. ja és abból is csak egy bizonyos verziójúval fordul a bizonyos kernel verzió. szerintem ez így azért kicsit necces.

Ja a kód nem attól lesz szar, hogy ilyen vagy olyan kód stílust alkalmaz, azt lehetne mondjuk autoformat git hook-kal kezelni. Hanem attól hogy rosszul van szervezve, mert pl boldog-boldogtalan azt dobál bele amit akar. 

Legendák, mendemondák. Egyesek pont azért sírnak, mert nehéz elérni a mainline-ba kerülést. Pont, hogy nem az dobál bele bármit, aki akar. Egy ekkora kódhalmaznak biztosan vannak elavult, karbantartás nélküli vagy minimális karbantartást kapó részei. Milyen kódnak nincsenek? Amikor pl. a Windows-ban 10-20 éves bugokat találnak?

Ja a kód nem attól lesz szar, hogy ilyen vagy olyan kód stílust alkalmaz,

Rendszerető embernek a külalak is fontos, legyen az bármilyen munka. Épp úgy, egy áttekinthető kábelezés, mint egy jól formázott forráskód. Ezt max. a trehány emberek nem értik.

trey @ gépház

Mondjuk nem vagyok egy nagyon rendezett pasi, de akár kódolásnál, akár szerelésnél szeretek arra törekedni, hogy jól kinéző/átlátható eredmény legyen, és a fejem fogom néha, hogy egyes "szakik" mit ki nem adnak a kezükből "jólvanazúgy" felkiáltással (mert amúgy működik a végeredmény, de mégis...)

Legendák, mendemondák 

Hát keresd vissza a srácot, volt valami cikk is róla itt hup-on nem olyan rég, itt örültetek neki...

A külalak is fontos persze, de az elég relatív hogy kinek mi a szép.. Ezt egy automatizmusra kell bízni, mert elképesztő mennyiségű energia el tud menni arra mikor két (vagy több) fejlesztő elkezd vitatkozni azon hogy most hogy kéne formázni a kódot. Főleg egy opensource foson.

Nem ez a lényeg. Az a lényeg, hogy megcélzod-e a mainline-ba kerülést vagy sem. Ha igen, akkor megvannak a követelmények, érthető okokból. Ha nem célzod meg, akkor csinálsz amit akarsz. Ebben az esetben nekem az jött le, hogy a végső cél a mainline-ba kerülés. Ezért is kérdezett rá, hogy érdemes-e erre indulni.

trey @ gépház