Blíží se podpora Rustu v linuxovém jádře

Očekáváme, že v průběhu příštího roku dojde k zařazení podpory Rustu do ostrého linuxového jádra.

Kdo?

Já, Michael a další? :)

[Michal Kubeček]
"Kdo?"

Google, ARM, Microsoft? .... Chtelo by se mi k tomu neco dodat, ale radeji nic.

14. 12. 2021, 23:02 editováno autorem komentáře

Linus ;)

[klokan]
No co ja vim, tak ten se k tomu stavel vicemene neutralne. Skoro me prijde, jako bych mezi radky z jeho nezvykle celkem opatrnych vyjadreni cetl rezignaci. Ale to samozrejme muze byt jen muj dojem.

14. 12. 2021, 23:12 editováno autorem komentáře

Já jsem ho pochopil tak, že uznává, že nemá cenu lpět na C a že k tomu jsou dobré důvody. Je opatrný pokud jde o to, jestli tím bude zrovna Rust, resp. čeká, jestli se využití Rustu v jádře osvědčí a doopravdy přinese slibované výhody. Někde se vyjádřil tak, že nasazení Rustu do jádra zatím bere jako experiment.

Proč byste něco dodával? Mne jen zajímalo, kdo je ten zamlčený podmět "my" v té větě. Protože, jak už tu někdo podotkl, žádná solidní diskuse na toto téma zatím opravdu stále ještě neproběhla. Jen spousta nadšenectví a neustálého opakování mantry "memory safety", zatímco vážné připomínky a upozornění na reálné praktické problémy jsou buď ignorovány nebo bagatelizovány. I jen to, aby Miguel Ojeda a spol. přiznali, že opravdu chtějí nastolit stav, kdy by přinejmenším všichni maintaineři a revieweři museli ovládat rust a rozumět jeho integraci do jádra do takové míry, aby byli schopni provádět review a adaptovat kód (což není ani zdaleka triviální), trvalo několik měsíců, během kterých usilovně mlžili a ignorovali přímé dotazy.

Takže ne, opravdu zatím, na rozdíl od autora zprávičky, nevidím nic, na základě čeho bych očekával rustifikaci jádra během roku 2022. Můj osobní názor na to, jestli by k ní vůbec mělo dojít, je úplně jiná otázka, to už jsem před časem pochopil, že v prostředí jako tady nemá smysl řešit.

“Jen spousta nadšenectví a neustálého opakování mantry "memory safety", zatímco vážné připomínky a upozornění na reálné praktické problémy jsou buď ignorovány nebo bagatelizovány.”

Nadšenectví patří ke každému hypu. Před dvaceti lety panovalo stejné nadšení okolo Javy.

15. 12. 2021, 09:23 editováno autorem komentáře

Ta diskuze probíhá, jenom na trochu jiné úrovni, než jsou komentáře na root.cz. Číst ji můžete stejně jako kdokoli jiný, odkazy najdete mimo jiné třeba in a this-week-in-rust.org. Důvody jsou známé, stejně jako názory (celkem tomu otevřené) stěžejních vývojářů jádra. Známé jsou i odpovědi na otázky a námitky. Ano, mít v kernelu víc jazyků znamená, že review a integrace jsou složitější, to nikdo nikdy nepopíral. Jde o to, jestli výhody za to stojí a i tady jsou známé a solidní argumenty, včetně toho, že pro dohlednou budoucnost se uvažuje o používání Rustu v leaf modulech jádra tak, aby se to centrálního jádra zatím nedotýkalo a aby bylo možné vyhodnotit náklady a přínosy. Dalším důvodem k tomuto přístupu je jiná rozumná námitka, a sice že Rust oficiálně nepodporuje řadu architektur, na kterých jinak Linux funguje. Naopak memory safety není žádná nadšenecká mantra, je to extrémně důležitá vlastnost zejména pro software, jako je jádro.

Že zrovna vy jste se neobtěžoval si nic z toho vyhledat na tom nic nemění. To, že já Rust neumím a nechci se ho učit a proto se nesmí používat taky není rozumný argument. Je to jako se vším. Jste vývojář jádra? Pokud ano, uveďte své seriózní námitky v příslušném kanále (LKML) a třeba budete vyslyšen, třeba ne a podřídíte se. Pokud ne, nekňučte a berte, co se vám dává, nebo si Linux forkněte a udržujte verzi zaručeně bez Rustu. Pokud najdete dost lidí, kteří budou tenhle váš pohled sdílet, třeba se z toho stane životaschopný projekt.

Ta diskuze probíhá, jenom na trochu jiné úrovni, než jsou komentáře na root.cz.

Ne, root.cz jsem opravdu nemyslel.

odkazy najdete mimo jiné třeba in a this-week-in-rust.org

Ne, ani tohle jsem nemyslel.

Jste vývojář jádra? Pokud ano, uveďte své seriózní námitky v příslušném kanále (LKML) a třeba budete vyslyšen

Zkoušel jsem to v LKML i na LWN a byl jsem ze strany rust fans zcela ignorován, stejně jako mnoho dalších. Teprve po několika měsících konečně na rovinu přiznali, jaký stav je jejich skutečným cílem. Tedy že nejde jen o nějaký izolovaný experiment pro pár driverů, kterých si ostatní nemusejí všímat.

Právě protože sleduji ty relevantní diskuse, vím, že ta věc není ani zdaleka ve stavu, kdy by se dal očekávat brzký merge, a že nějaká vážná diskuse o principiálních otázkách, jako je efekt na procesy správy jádra, ještě vůbec neproběhla. Pořád je to v rovině "rust is memory safety, memory safety is good, mkaaay, you need rust, mkaay."

[Michal Kubeček]
"Proč byste něco dodával"
Protoze, kdyz vidim, jakym zpusobem to cele probiha, formu diskuze s mistnimi fans a ktere firmy to uz delsi dobu podporuji, rapidne to snizuje moji duveru. Jenze ani ja - stejne asi jako vy - nechci se o tom proste hadat s mistni fans, proto k tomu nic nechci dodavat.

Jinak s Vami naprosto souhlasim.

15. 12. 2021, 11:36 editováno autorem komentáře

Tak predsa len motyka vystrelila a Rustu sa darí to čo sa nepodarilo D, Go, Swift-u a ďalším jazykom. Aspoň niečo tu ostane po Mozille.

Go a Swift asi do jádra nemíří ne? By si musely natahat celej svůj runtime :-)

To by byla zvlášť u Swiftu docela zátěž. Go nemá velký runtime, ale má GC, to asi v jádru nechceme.

Hlavně by nic užitečného nepřinesli. O Rust je v jádře zájem kvůli bezpečnosti a schopnosti líp odchytávat bugy staticky. Go i Swift mají naopak za cíl usnadnit život vývojářům a zvýšit produktivitu. To v kernelu není tolik důležité.

Hlavně C++ Linus zaříznul.

13. 12. 2021, 13:23 editováno autorem komentáře

Ty další zmíněné jazyky ale vůbec nejsou vhodné pro kernel.

A Fortranu, Lispu, Prologu, R ani SQL…

Teď vážně, Rust je přesně na úrovni pro jádro (systémové programování), ty jiné zmíněné jazyky mají každý jinou oblast, kde se projevují jejich výhody.

Nemá NetBSD v jádře LUA ?

Kdyz to tak vezmete, tak moderni prohlizec anebo SQL databaze maji a architekture OS kernelu celkem blizko.

Jakmile nejaky projekt implementuje vlastni memory management, vlastni scheduler, runtime a zamykani a tak uz to ma OS celkem blizko.

V coding guideline Mozilly, vybrali urcitou podmonozinu C++, kvuli ruznym problemum, kterym celili. Dale napr, nebylo mozne otevirat a zavirat soubory mimo hlavni thread a resilo se to tim, ze se posilala zprava do hlavniho threadu, aby nejaky soubor otevrel. Neco z tome pripomina omezeni, ktera prinasi vyvoj kernelu. Nakonec se nedivim, ze ten Rust vznikul.

Rust de facto vzniknul jak DSL pro psaní jádra prohlížeče. A pak jej zevšeobecnili :)

13. 12. 2021, 16:03 editováno autorem komentáře

Opravdu by mne zajimalo, jak by fungoval Unixovy operacni system "z druhe strany", ktery by nekdo naprogramoval stylem ze by vzal nejmensi mozne monolyticke jadro typu 4.xBSD/"SystemV", inspiroval se nejakymi chytrymi features typu IPC Mach (OS/X) a binder, pridal k tomu slusne udelane kernelove eventy + se mirne inspiroval u "user32" WinAPI kde jsou nektere veci vyresene lip nez v POSIXu.

A do toho narval zakladni userland z OpenBSD + dalsi baliky z Ubuntu.

Misto systemd, rustu, ruznych 'fancy' compositoru, atd.

BSD? Posledne jsem do OSX instaloval pres brew gnu sed, protoze ta jejich verze umela velky h***o, a to nepouzivam zadne fancy prepinace :-)

trochu z cesty porovnavat kernel vs sed ;-)

Myslel jsem to typove, kdyz clovek otevre zdrojaky userlandu OpenBSD/NetBSD a nekdy i FreeBSD a srovna to s ekvivalentem v Linuxu a OS/X, tak rozdil v pristupu je obrovsky.

Videt to je znacne i ve 'library version hell' (nebo jak se tomu rika). Ted jsem zrovna neco prekladal na Debianu na ARMu a nejak se mi system dostal do stavu, kdy dynamicky linker u meho primitivniho programku byl nespokojeny se symbolem strcmp ... to mne dostalo.

sed obecne umi hovno, hlavne dialekt regularnich vyrazu je dnes hodne zastaraly. naucte se perl https://blog.parseltongue.io/2020/10/25/perl-sed-grymoire.html

Bohužiaľ, v tomto sú GNU utility tie divné, lebo robia veci mimo POSIX štandardu. Na tom si vylámali ľudia u nás na škole zuby. Nevedeli to a učili sa ovládať GNU utility, v škole sme mali na skúške freebsd.

Stále ale lepšie GNU sed, než perl. Perl je šiesta rana kristova.

K čemu by to bylo dobré?

A proč si Rusťáci nenapíšou vlastní kernel a musí místo toho prznit Linux?

13. 12. 2021, 14:50 editováno autorem komentáře

1. Napíšou: https://www.redox-os.org/
2. S tím przněním bych brzdil. Linux nebyl, pokud vím, zamýšlen jako pomník jazyku C a jestli tam má nebo nemá být jiný jazyk vyšší úrovně, si zaslouží seriózní debatu.

Já bych tam dal Prolog ;)

Nebo Haskell.

Haskell není dost abstraktní ;)

Nie radsej brainfuck?

Ne, toto by bylo jeste lepsi : https://github.com/tkohout/OSTRAJava

Můžeš odkázat na tu seriózní debatu? Já zatím žádnou neviděl

Můžeš nějakou rozjet. Začal bych tím, že se zdržíme expresivních výrazů typu "prznit".

No to jsem zvědavý.

Co třeba LKML?

[Ink]
"a jestli tam má nebo nemá být jiný jazyk vyšší úrovně, si zaslouží seriózní debatu."

Aha...

Jsou posedlí rustifikací, všechno chtějí překopat :)

Já bych všechny ty rasty zakázala.

Rust by se hodil všude, kde se nepovoluje dynamická alokace paměti, tam by jeho přínos vyniknul.

Asi myslíte GC. Dynamickou alokaci paměti Rust samozřejmě umí stejně jako každý jazyk.

myslim si, ze to dopadne jako s tim systemd.
Investuje se hodne prace, nakonec to bude i fungovat jako predtim, ale nic noveho to neprinese.
Tak uz nekdy chodi.

Pokud se použije jen podmnožina Rustu jako “lepší C”, přinese to aspoň bezpečnější kód. Pokud se použijí i (rádoby)sofis­tikované abstrakce, bude z toho nakonec bolehlav. Rust je nízkoúrovňový jazyk a IMHO se do jádra hodí, ale bez některých konstrukcí vyšší úrovně, které kód spíše komplikují, než aby pomáhaly.

Musím souhlasit. Ta sofistikovaná abstrakce je tak "geniální", že kolikrát program zamlží do něčeho, čemu rozumí možná jen autor.
Ale všechno, co má potenciál vytlačit Python z Linuxu, kvituju ;-)

Buď zamlží, nebo sníží efektivitu. Obojí je špatně.

Z konstrukcí vyšší úrovně, které nabízí Rust, se do jádra asi nehodí async/await (I když...) Jinak nevím, co by se mělo vyloučit, traitové objekty se zrovna výborně hodí, stejně tak Option a Result.

No on už samotný pojem "konstrukce vyšší úrovně, které kód spíše komplikují, než aby pomáhaly" je dost podezřelý.

Do jisté (malé) míry na tom něco je pokud se bavíme o nízkoúrovňovém kódu. Tam je někdy opravdu důležité, aby zdroják a výsledný assembler si pokud možno odpovídaly 1:1. Ranné verze Rustu měly výjimky, dědičnost i GC ale tyhle věci byly odstraněné právě proto, že usoudili, že do systémového jazyka nepatří (na rozdíl od např. jazyka pro GUI aplikace jako je Swift).

Proč nepoužít C++?

Protože to Linus napsal. (jiný důvod jsem nenašel)

Mně je to celkem jedno v čem to mají, jen si někdy říkám, že víc než objektivní argumenty se tady jedná o víru.

C++ Linus z principu odmítá, proti Rustu nic nemá, takže proto.

C++ by mělo tu výhodu, že interoperabilita s existujícím C kódem je extrémně jednoduchá. Na druhou stranu Linusovy argumenty proti C++ jsou rozumně a z představy, že v jádru by strašilo C++, mi běhá mráz po zádech.

Zajímavé, že nové projekty se C++ v jádře nijak nebrání. Třeba Zirkon používá subset C++17:

https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/cxx

Trvat na tom, že nějaká feature je v projektu zakázaná se dá řešit přímo na úrovni CI. Možná Linus jen nemá rád C++ - ono když něco nesnášíš, argumenty si vždycky najdeš. Ale rozhodně bych to neinterpretoval tak, že C++ v jádře je špatné...

Klíčové je slovo “subset”. Rust i C++ mají společnou množinu problematických vlastností, které tolik nevadí v jádře, ale na vyšší úrovni ano. Pro Rust asi hovoří jednoduchost syntaxe oproti C++. Nicméně jádro jde psát v kde čem, Microsoft si napsal jádro OS v C# a v Japonsku měli výzkumný projekt, v jehož rámci napsali jádro v Prologu (resp. jeho paralelizované variantě), to jen Unix a jeho dědicové závisí na C (ostatně C vzniklo kvůli portaci Unixu).

Jenže C++ je otesánek, který nemá nikdy dost. Přidává další a další vlastnosti a způsoby, jak řešit totéž. S každou další revizí budeš pořád dokola s někým řešit, že tohle je fakt cool vlastnost a hodilo by se ji povolit.

Zircon, pokud se nepletu, je pořád výzkumný projekt a hračka Google. Argumentovat tím, že někdo napsal nějaké jádro v nějakém jiném jazyce sice můžeš, ale bylo by dobré srovnávat srovnatelné a s Linuxem se může srovnávat máloco.

To nic nemění na tom, že C++ a Rust jsou dvě strany jedné mince. Mírně u mě vyhrává Rust díky méně hnusné syntaxi, ale jinak to je prašť jako uhoď.

“víc než objektivní argumenty se tady jedná o víru”

Kde nejsou argumenty, nastupuje náboženství a magie :)