Budeme mít linuxové moduly napsané v Rustu?

Jak by jej tedy šlo využít, kdyby nesměl být vyžadován při kompilaci všech options?

Linuxové moduly lze psát v Rustu už teď. Upřímně řečeno, jsem velký fanda Rustu, ale tohle mi připadá celkem na nic. Jeden z hlavních přínosů Rustu, tj. prokazatelně bezpečná práce s pamětí, se v tomto případě neprojeví, protože každý modul, ovladač atd. pracuje s datovými strukturami vybudovanými a spravovanými v C v hlavním jádře. A těžko si umím představit, jak využívat další vlastnosti Rustu (traity, polymorfismus, paralelizaci apod) v jaderném kódu, kde veškeré volající funkce opět předpokládají sémantiku C. Lepší je používat Rust tam, kde se jeho výhody naplno projevují.

Nějak se začít musí.
Moduly, pak postupně dál a dál a zvolna (za roky a roky) C omezit na nezbytné minimum.

Jestli by v takovém případě nebylo lepší začít spíš u soběstačného kódu z centrálního jádra, který toho moc nesdílí se svým okolím. Např. takový plánovač procesů. Ten pracuje se složitými datovými strukturami a algoritmy, kde by Rust jistě znamenal přínos, a přitom by problémů s interoperabilitou bylo nesrovnatelně méně. I když je celkem jisté, že přes Linuse by se tohle nedostalo. Linus se už vyjádřil, že sice nemá nic proti Rustu jako takovému, ale do kernelu nechce zavádět žádné další jazyky.

2. 9. 2019, 09:46 editováno autorem komentáře

Máš technicky pravdu, ale to by bylo zase větší riziko do začátku...

…u soběstačného kódu z centrálního jádra, který toho moc nesdílí se svým okolím. Např. takový plánovač procesů.

Scheduler? Tak to není moc dobrý příklad. Ale nejsem si moc jistý, jestli vůbec nějaký existuje.

To prave nejde - Rust by musel stabilne podporovat vsechny doposud podporovane architektury.

To je samozřejmě dneska stále jedna z nevýhod Rustu proti C/C++, ale ruku na srdce. Kolik těch architektur Linux DOOPRAVDY podporuje, potažmo v tom smyslu, že se na nich používá v produkci na komerčně relevantním hardware a někdo platí za jejich podporu? To bude amd64, ARM/Aarch64, POWER a perspektivně snad RISC-V. Na těch Rust dneska funguje. Je nutné si uvědomit, že je jen otázkou času, kdy podpora procesorů, jako SPARC, HPPA, m68k a spol. v Linuxu stejně odumře, takže stanovit, že u nových fičur jádra se s nimi už nepočítá by mě celkem nešokovalo.

Mozna by to slo vyuzit pro ovladac FS, ktery pracuje s vlastnimi komplexnimi datovymi strukturami, anebo pro neco co za "jizdy" parsuje obsah IP packetu.

Pro kód co "za jízdy" pracuje s potenciálně nebezpečnými daty by to jistě mohlo dobré. Ostatně je zajímavé se podívat na politiku Mozilly ohledně nasazování Rustu. Mozilla Rust doporučuje v zásadě ve třech situacích:

1. Tam, kde se pracuje s nekontrolovaným inputem a u C/C++ by hrozily overflow, leaky, injekce apod.

2. Tam, kde přepsání existujícího kódu do Rustu může přinést znatelné zvýšení výkonu díky optimalizaci paměti, paralelizaci atd. jako to bylo u CSS podpory ve Firefoxu.

3. U zbrusu nových projektů

Aby se pak z jadra nestalo neco, cim je dnes Skype (pro Windows ci Android) - pomala gigabajtova virtualizovana webova aplikace :(

Jak souvisi rustove moduly linuxoveho jadra s electron based aplikacemi (pricemz virtualizace to vubec neni)?

Cim vyssi uroven jazyku tim vetsi praseni. Jednak kvuli tvorbe kodu neprogramatory a pak kvuli mnoho abstraktnim vrstvam. Neexistuje projekt, ktery by pouzitim vyssiho/komplex­nejsiho jazyka nabyl na rychlosti nebo se zmensil. Low level asm/C v obou techto metrikach vede, ale poklada urcite naroky na tvurce programu.

"Cim vyssi uroven jazyku tim vetsi praseni."

To je... odvazne tvrzeni.

"Neexistuje projekt, ktery by pouzitim vyssiho/komplex­nejsiho jazyka nabyl na rychlosti nebo se zmensil."

Pomineme to, ze bezpecnost >> rychlost.
S touhle filosofii by se melo v kernelu zahodit i to C, ne? (Nemluve o tom, ze to tak ci onak neni pravda. Viz gecko vs servo. Samozrejme to neni zasluha _jen_ lepsiho jazyka, ale i toho, ze proste v tom lepsim jazyce se dalo snadneji napsat neco rychleho.)

"Viz gecko vs servo"
Odkaz na test na 1 core a bez GPU mate? (a doufam ze se bude porovnavat kod stejneho stari - rekneme 6 ci 12 mesicu od doby vzniku kodu a ne nejaky desetiletim nabalovany balast).

Bezpecnost je relativni - jazyk vam ho nezaruci. A pokud se jedna kvuli bezpecnosti treba i o jen primitivni kontrolu rozsahu pole, tak kazdy pristup musi kvuli ni provest boundary check? - tak to vime jak to dopadne s vykonem. A o tomto jsem mluvil - ze prechod na vyssi jazyk (treba prave z duvodu "bezpecnosti") bude znamenat pomalejsi sw.

Rust je podle benchmarků rychlejší než C.

Hmm ... Podle jakých? Ušitých na míru Rustu? Idiomatický Rust a idiomatické C? Neřekl bych. Každý napíše benchmark kde jeho favorit vyhraje a ten druhý to projede.

Prvně by se slušelo říci, že porovnávat Rust a C nedává moc smysl. V Rustu můžu napsat nachlup stejný kód jako v C a rychlost bude stejná. Porovnávat se dá leda tak idiomatický Rust s idiomatickým C. Ano, v tomhle případě je Rust v některých věcech rychlejší. V C mám dva ukazatele a překladač neví jestli to je jeden objekt nebo dva různé. C tedy musí být konzervativnější, ale Rust to ví a může optimalizovat mnohem agresivněji. Na druhou stranu, Rust je v některých věcech pomalejší. Sice zrychluje, opravuje chyby, ale stále tu máme dost problémů. Stačí se podívat na label:I-slow.

A to píšu jako velký fanoušek Rustu a někdo, kdo se Rustem už přes 2 roky živí.

Jo, klidně, ať to píšou v Rustu. Ale navrhuju začít na zelené louce. Založíme projekt Rustux

Rustix, jedině Rustix!

Takovy projekt uz existuje - Redox