Názory k článku Kernel panic s QR v Linuxu 6.12, neshody Rust vývojářů se správci částí jádra

UB s Tebou, bratře, takhle jednoduchý je svět a Ty jsi nám ho teď celý vysvětlil.

Tak ale co? Cé je jaké je...

driv nez jsem to cetl jsem si rikal zase rust.
rust pro bazlive, ktere musi nekdo hlidat a boji se delat chyby. ja nechci aby me nekdo ovladal a nemohl bych udelat chybu v alokaci pameti

Ono to není tak černobílé.

Doporučuji si přečíst odkazovaný blog. V podstatě se nedivím ani jedné straně. Každopádně to neznamená, že je to optimální...

1. 9. 2024, 05:05 editováno autorem komentáře

Ono by to mohlo fungovat, kdyby celá ta myšlenka rustu v jádře vznikla z oboustranné potřeby. Ale to není ten případ. Ze strany rustařů je motivace jasná: usoudili, že model "kernel in rust" znamená příliš mnoho práce a bylo by krajně nejisté, že by se výsledek opravdu prosadil jako mainstream (tím spíš, že takové projekty už existují, ale nijak zvlášť se neprosadily), proto se rozhodli pro (pro ně) pohodlnější model "rust in kernel". Ze strany stávajících vývojářů a maintainerů jádra tu ale žádná velká poptávka nebyla, i ti nejoptimističtější to viděli a vidí spíš jako zajímavý experiment, pokud s tím nebude moc práce navíc.

A to je kámen úrazu. Představa, že jádro předěláme na dvojjazyčné, aniž by to znamenalo podstatnou míru práce a komplikací navíc, je naprosto naivní, to byl spíš marketing těch, kdo rust do jádra chtěli dostat. (Ať už tomu sami opravdu věřili nebo jen vědomě lakovali situaci na růžovo.) Takže když se nevyhnutelně ukázalo, že proklamace o tenkém rozhraní mezi dvěma oddělenými světy, kterého si stávající vývojáři vlastně nemusejí ani všímat (natož toho, co je na druhé staně), se neslučují s realitou a že ve skutečnosti bude potřeba hodně vstřícnosti a ústupků z obou stran, objevily se i první konflikty.

Takže to dopadlo jak muselo. Na jedné straně stávající maintaineři a vývojáři, kteří mají pocit, že mají své práce a problémů dost, aby si museli ještě přidělávat další nutností vycházet vstříc a přizpůsobovat stávající modely a řešení potřebám vývojářů rust in kernel. A na druhé straně má komunita rust in kernel pocit, že stávající maintaineři a vývojáři nejsou dostatečně vstřícní a ochotní přizpůsobit svůj kód jejich potřebám. Oba ty pocity jsou vlastně naprosto oprávněné a jako závěr mi tak vychází, že primární problém je ve skutečnosti v tom, že to spojení vzniklo dost uměle a nevycházelo ze skutečné vzájemné potřeby. Bez ní se to dá udržet pohromadě jen pomocí velkého množství síly, ale to by nadělalo víc škody než užitku, takže doufám, že na takové řešení nedojde.

Tak nějak jsi vynechal z příběhu samotného Linuse. Poptávka po nějakém jiném jazyce v kernelu, než je C, existuje už poměrně hodně dlouho a důvody jsou zjevné. A Rust byl první takový jazyk, který Linusovi dával smysl. Není to tak, že by si to lidi z Rust komunity nějak vydupali jako svoji hračku.

A že se v Rustu nebo jiném jazyce nepovede jen tak sestavit jádro srovnatelné s takto aktivním projektem vyvíjeným za masivní podpory celého IT odvětví 30 let, není snad také překvapivé. Osobně doufám, že plnotučné jádro v něčem "Rustu podobném" časem bude a C bude moci na zasloužený odpočinek.

Tak nějak jsi vynechal z příběhu samotného Linuse.

Nevynechal, ten patří do kategorie i ti nejoptimističtější to viděli a vidí spíš jako zajímavý experiment, pokud s tím nebude moc práce navíc.

Osobně doufám, že plnotučné jádro v něčem "Rustu podobném" časem bude a C bude moci na zasloužený odpočinek.

Uvidíme.

muzete v rust ovlivnit implementaci Box?
rust is dead and rust is death.

(Na doplnění editací komentáře už bylo pozdě.)

Osobně doufám, že plnotučné jádro v něčem "Rustu podobném" časem bude a C bude moci na zasloužený odpočinek.

Osobně proti takovému scénáři nic nemám. Naopak, považoval bych ho za mnohem přínostnější pro všechny zúčastněné (stávající linuxové vývojáře, rustové vývojáře OS i uživatele) než ten scénář, o který se snaží "rust in kernel" komunita. Jen s výhradou, že i kdyby (céčkový) Linux opravdu "upadl v zapomnění", nebude to ani zdaleka znamenat, že C bude moci na zasloužený odpočinek.

Těch důvodů pro Rust v jádře je víc a ty netechnické mi teď přijdou i důležitější.

Je to také hodně o generační obměně. Vývoj jádra a přilehlého okolí potřebuje novou sílu / novou generaci jako prase drbání.

Když se při té příležitosti vymetou pavučiny, překonané koncepty, zamotané do nezdokumentovaných špagety kódů, tím lépe.

Bez velké míry OBOUSTRANNÉHO respektu to nepůjde. Nutností je velká míra chuti komunikovat a věci řešit. Nikoliv nevraživost a házení klacků pod nohy. A v současné kapitole, ti starší teď tahají za delší kus provazu.

IMHO: Buď se tu spolupráci podaří naladit a rozjet, nebo současné jádro vymře a s bude nahrazeno jiným projektem, při kterém se propálí spousta energie. A pokud se tak (za mnoho let) stane, možná to nakonec bude i dobře.

Těch důvodů pro Rust v jádře je víc a ty netechnické mi teď přijdou i důležitější.

To je možná právě ten největší problém vůbec: že ti, kdo by rust v jádře rádi viděli, k tomu mají většinou hlavně netechnické důvody a ty technické považují za druhořadé.

S výrokem

"ti, kdo by rust v jádře rádi viděli, k tomu mají většinou hlavně netechnické důvody a ty technické považují za druhořadé."

vůbec nesouhlasím.

Naopak, od začátku to bylo především o technických důvodech, ale že větší překážkou se teď stávají ty netechnické, neznamená, že ty technické by byly druhořadé (ve smyslu nepodstatné).

Já teda vidím všude ty technické, třeba Asahi Lina o tom postuje dost pravidelně, a vyvíjí asi největší současný driver v Rustu (GPU pro Apple Silicon macy).

Jaké jsou konkrétně ty netechnické důvody? zdá se že je znáš :)

Ten pochod "kernel in rust" bych rad videl na necem easy.. rekneme ten prvni sdilenej release (linux - 0.01 ~ 10K LoC), ktery by poskytoval zakladni multitasking, mm, fs a I/O.

A podobne by to mohli rozvijet - s tim ze budou stejne jen syscally a ioctl k driverum - takze userspace nepozna, ze je jadro rezave :)

> (tím spíš, že takové projekty už existují, ale nijak zvlášť se neprosadily)
Zde bych si tě dovolil opravit: https://www.redox-os.org/news/this-month-240731/

Dovedu si představit, že někteří odvážlivci začnou Redox zkoušet nasazovat na produkci.

Aby to nakonec nedopadlo tak že bez ohledu na to, jak když se bude Linux cukat, tak si tím vytvoří konkurenci. Však jde hlavně o kernel, že. User-space se může překlopit celé. Ovladače se podle potřeby přepíšou...

Vůbec bych to neviděl jako vy.

Za hlavní problém jazyka Rust v jádře Linux ale třeba i v NuttX a dalších vidím problém s hladkým použitím vývojového toolchainu.
Pokud jsou projekty primárně pro produkční nasazení kompilované GCC, tak je podle mě nutné, aby Rust končil na stejném backendu, do kterého se překlápí i podrobná nastavení architektury procesoru a ABI. Nutit běžné uživatele a vývojáře do používání slepence, kdy se musí pomodlit, že u stadardního nastavení třeba pro ARM sedne ABI GCC na LLVM a najít překlad nastavení přepínačů a další, co není k 1:1 je špatně.

A zde všichni, kdo bázní o Rustu a i někde na něj získávají zdroje na své aktivity, PR a další, tak ve skutečnosti nejsou ochotní investovat nutné minimum, aby Rust GCC projekt pokročil tak, aby byl použitelný. DO projektu se zapojil můj student, nyní absolvent, Jakub Dupák a něco pro to použitelnost udělal (Rust-GCC/gccrs commity). To vše ovšem zadarmo, když končil, ptal jsem se do mnoha směrů, SUSE, RedHat, OSADL, on i v EbedCosm, pro které zdarma dělal, jestli se najde financování, aby mohl na projektu pokračovat. Všem je to vlastně jedno a dělají jen PR, jak jim na projektech záleží, takže nakonec vzal práci na Rustu u firmy, kde očekávám, že i přes původní sliby, že se vyvíjí zavřeně jen dočasně, tak nakonec skončí ve stejném zapomnění jako nadějný návrh nového principu mikro-jádra CoyotOS, na jehož výsledky jsem se moc těšil, ale otec jeho myšlenky se se sliby nechal zaměstnat u stejné firmy a pak jsem o něm nic neslyšel Jonathan S. Shapiro a nakonec stejně odešel jinam.

Ono s RedHat/IBM i SUSE je to stejné i v automotive, kde dělají vlny s kontejnery na kolech, ale to, že by pod tím mohlo být jádro, které zprávu po řídicí sběrnici CAN/CAN FD/CAN XL doručí dříve, než bude chodec přejetý, také nikoho nezajímá. Tak sami jsme se dali alespoň do tetování, opět bez zájmu automobilek a dalšího zadarmo, protože je to potřeba udělat (CAN Latency tester) a zkoušíme se bavit s RT kernel komunitou, co by šlo udělat pro zlepšení. Přitom i na RT jsou při zátěži latence 10 ms. Na stejném HW jsme na RTEMSu někde na 60 usec, viz náš projekt RTEMS CAN subsystému vycházející z mého původně i na RT dobře vycházejícího driveru LinCAN. Dokumentace v a výsledky na RTEMSu diplomové práci pana Lence. Další mnou vedené závěrečné práce zde.

Pokud nebude Rust v GCC, tak jako řešení pro rozumnou integraci je přejít s vývojem Linuxového jádra pro všechny na LLVM a u něj je velmi pravděpodobné, že až GCC pro nepoužívání v kritických/zá­sadních projektech zchřadne, tak se změní financování LLVM tak, že jeho otevřená větev také použitelná nebude. Slyšel jsem, že Apple do LLVM mainline správný scheduling pro M1, M2 atd... posílat nemíní a komunitu si chová v kleci ať něco vytvoří a on to zavřenou verzí zhodnotí. Přesně to, před čím RMS vždy varoval.

Rust do kernelu ? Proc ?

Kdy presne prestalo platit zakladni pravidlo IT : "Funguje to ? Tak do toho nejeb ..."

Fungovaly i pazourky a jehličkové tiskárny.

a fungovaly dobre.

radsi at je paralelni rust jadro, nez rust v linuxu.

> a fungovaly dobre.

A teď fungujou tak špatně, že je skoro nikdo nepoužívá. A to se toho kusu šutru nemusel nikdo ani dotknout a stejně funguje stále hůř a hůř.

Problém s paralelním rust jádrem je v tom, že vývoj na zelené louce nefunguje. Jestli je cílem pálení člověkohodin (třeba jako koníček), je vývoj paralelního jádra dobrý nápad. Jestli je cílem lepší OS, je lepší cesta postupná modernizace jednotlivých komponent.

Problém je, že fungování Rustu je tak odlišné, že nesedí ani komunikační interfacy. Pak půlku času řešíš jen to, aby interoperoval starý a nový kód.

> Kdy presne prestalo platit zakladni pravidlo IT : "Funguje to ? Tak do toho nejeb ..."

Ono vlastně opravdu neplatilo nikdy. Samotné "funguje to" je nepříjemně relativní a neostrý pojem.

Otázka je, zda je na tohle Rust vůbec vhodný jazyk.

• (1) Nejde to psát jen v Safe Rustu.
• (2) Unsafe Rust je ještě složitější než C. Hlavně kvůli pravidlům pro aliasing.
• (3) Kdyby to šlo psát jen v Safe Rustu: Safe Rust se specializuje na RAII, na správu paměti per jednotlivé objekty, což je IMO nevhodné pro výkonný kód. Kde je mnohem lepší se zabývat skupinami objektů.

(3) Kdyby to šlo psát jen v Safe Rustu: Safe Rust se specializuje na RAII, na správu paměti per jednotlivé objekty, což je IMO nevhodné pro výkonný kód. Kde je mnohem lepší se zabývat skupinami objektů.

Můžeš to prosím víc rozvést v kontextu jádra? Nerozumím, jak v jádře/driverech se více pracuje s alokací/uvolněním skupin objektů. Pod skupinami objektů si mám představit pole structů?

Díky.

> Nerozumím, jak v jádře/driverech se více pracuje s alokací/uvolněním skupin objektů.

V jádře k tomu slouží slab alokátory, které alokují objekty stejného typu u sebe a cachují zinicializované objekty, aby se nemusely pořád dokola inicializovat.

Navíc, když objekty daného typu nepotřebují deinicializaci, tak stačí paměť označit jako volnou a není třeba strukturu do hloubky procházet.

> Pod skupinami objektů si mám představit pole structů?

Třeba. Ale může to být i nějaký scratch buffer s krátkou životností, kde se alokují objekty různých typů a který se pak celý uvolní naráz - aniž by bylo třeba procházet jednotlivými objekty.

Cílem je dělat málo velkých alokací (než hodně malých). Tím se snižuje prostor pro problémy. Alokace totiž může selhat, což btw Rust také nemá zrovna dobře ošetřené (možná to nemá dokonce vůbec ošetřené a funkce prostě zpanikaří).

Problém s adopcí Rustu do Linuxu není technický, ale organiční. Technicky nic nebrání tomu, aby se Rust v Linux kernelu začal používat ve velkém. Že to jde a velmi dobře funguje dokázal Google s Androidem i Microsoft s Windows.

Google i Microsoft jsou ale komerční firmy a mají ale ten luxus, že mohou říct: přepisujeme Android postupně do Rustu, jdeme tímto směrem a vývojáři to buď akceptují, nebo budou nahrazeni jinými. Linux tento luxus nemá, někteří core vývojáři Rust neakceptovali a vypadá to, že ani akceptovat nechtějí a je velmi těžké je někým nahradit (zčásti proto, že v C to moc lidí dělat nechce, což by Rust taky řešil).

Je to zajímavá situace, ale pro Linux bohužel ne moc dobrá a brzdí ho to ve vývoji. Trend je nastavený jasně, memory-unsafe jazyky nepatří ani do kernelu a velcí hráči to už pochopili a jdou tímto směrem. V Linuxu to ještě bude delší cesta.

Já si taky myslím, že Rust v kernelu vlastně žádný kernel vývojář nechce a celé to bylo způsobené jen obrovským tlakem z venku... A teď ta bublina praská...

Existuje projekt Redox (https://www.redox-os.org/) - tento mi dává teda větší smysl - ať si tito lidi udělají vlastní kernel a uvidíme jestli to bude lepší nebo ne.

Mi je Rust celkem ukradený, ale vidím pozitiva v tom, kdyby byla nějaká konkurence - 2 jádra, různé jazyky, krásně uvidíme ty rozdíly, ale nejen v bezpečnosti, rozdíly i v tom jak jednoduché je něco přidat, jak udělat fs, jaký má ten jazyk vliv na výkon, atd...

Rust v kernelu chce docela dost vývojářů, ale bohužel existuje i docela velká skupina vývojářů, kteří se Rustu brání. Asi se to dalo čekat, je to velká změna a lidskou přirozenosti je bránit se velkým změnám.

Začít dělat nový kernel v Rustu na zelené louce není cesta, nedává smysl zahodit desítky let vývoje. Nikdo soudný touto cestou nepůjde, nedělá to ani Google s Androidem ani Microsoft s Windows. I komerční firmy vědí, že je to potřeba dělat postupnou integrací do existujícího produktu a začít u těch nejkritičtějších částí.

Rád byste konkurenci, ale Linux už konkurenci má. Na serverech třeba Windows a i když aktuálně Linux Windows na serverech válcuje, nemusí to tak být navždy. Pokud Microsoft postupně přepíše Windows do Rustu, tak se to projeví na množství bezpečnostních chyb, najednou bude Windows mnohem bezpečnější než Linux a na tohle budou samozřejmě zákazníci slyšet. Tady se trochu bojím, aby Linuxu neujel vlak, protože Google i Microsoft už do vlaku memory-safe jazyků nastoupili, ale v Linuxu to ještě docela drhne.

Windows není konkurence - není open source a na serverech se hodí jen na legacy věci, které nejsou pro linux a jsou z nějakého důvodu potřeba. Windows na serveru prostě nikdo normální už dnes nechce.

Tou konkurencí jsem myslel něco, co je napsané v něčem jiném než C. Hodně kernelů je napsaných v C, některé v C++ (Fuchsia), ale v rustu žádný použitelný zatím neexistuje. Proto vidím ten benefit v tom, že nám konečně Rust komunita ukáže, jak jednoduchý, bezpečný a výkonný ten kernel v rustu bude... Ale bude?

Rust v Linuxu nedává smysl - kernel píšou lidi co v umí perfektně C, ale ne všichni se naučí perfektně rust... A pokud bude rust v kernelu, tak to znamená, že všichni budou muset umět perfektně 2 jazyky (i ti rust vývojáři), jinak nebude dávat smysl, aby na tom pracovali. A pořád to bude z pohledu Rustu unsafe, protože tam je C.

Ne každý se ale chce učit Rust, a já je chápu. Když se podívám na nějaké issues v tom asahi linuxu, tak vidím "This is not our fault, it's memory corruption caused somewhere else..." - jenže toto není způsob jak řešit problémy - pokud nechcou řešti problémy a radši budou ukazovat prstem na C, tak tato spolupráce nikdy nebude fungovat, protože vzniknou 2 nesmiřitelné tábory v jednom projektu...

Ačkoliv jsem s Rustem začal taky, tak na nové projekty stejně preferuju C++, protože v Rustu nejsem produktivní a mám problém v Rustu číst kód ostatních (prostě mi to přijde nečitelné a nic s tím nedokážu udělat).

Lina celkem pravidelně nejen poukazuje na unsafe kód jinde v kernelu, ale posílá patche. Jak to občas dopadá ukazuje tady: https://vt.social/@lina/113051677686279824

Windows samozřejmě je konkurence Linuxu, aktuálně sice Linux na serverech Windows válcuje, ale to nemusí být navěky. Korporátům je jedno, jestli jejich aplikace běží na Linuxu nebo Windows a pokud Windows nabídne něco navíc oproti Linuxu (bezpečnost), tak okamžitě přejdou z Linuxu na Windows. A v USA se aktuálně bezpečnost docela dost řeší.

Lidi, co píšou kernel Linuxu, sice umí perfektně C, ale stejně je kernel plný bezpečnostních chyb, protože ani lidé, kteří umí C perfektně, v tom nezvládnou psát bez chyb, je to mimo možnosti člověka. Proto je Rust důležitý, chyby odchytí překladač.

Pokud Windows (nebo jiné systémy) tu transformaci do memory-safe jazyka udělají a Linux ne, tak to bude konec Linuxu, protože oproti Linuxu budou ty jiné systémy nabízet mnohem vyšší bezpečnost.

Navíc to není o ceně. Supportovaný Linux není výrazně levnější než Windows. A na menších serverech, např. věci ve firmě, vídávám "nekonečnou trial" verzi Windows Serveru. Spolu s desktopovou najel MS na model "WinRAR" a "Total Commander", protože je do budoucna lepší, aby se ajťák nemusel učit Linux.

2. 9. 2024, 12:32 editováno autorem komentáře

" chyby odchytí překladač"

Ne, neodchyti, takovy prekladac neexistuje a nikdy nebude, coz lze navic zcela exaktne a matematicky dokazat.

Tak maximalne vymeni primitivni chyby za chyby mnohem sofistikovanejsi.

Prekladac navic neumi zkompilovat sam sebe a jako bonus neumi ze stejneho zadani vyrobit stejny vysledek, je tudiz zcela nepredvidatelne nebezpecny.

Tys windowsy nikdy nide nevidel ze? Jinak bys nemoh do jedny vety napsat windows a bezpecnost.

Widle maji odjakziva a setrvale vzdy vse nastaveno tak, ze o nejake bezpecnosti nemuze byt vubec rec. Najdi si novinky win 2k25 ... MS se tam chlubi, ze bydefault budou dokonce pouzivat sifrovani u LDAPu ... teda nejspis neco na tema 3des.

Win 2k22 NEUMI fungovat bez tls 1.2. Kdyz to vypnes, lehne to. Mimo jine proto, ze MS nehorazne lze, protoze 1.3 ve skutecnosti vubec neumi.

Pokud mas .NET aplikaci, bydefault NEUMI ani tls 1.1. Ani v pozici klienta ne. Proste pokud neni tls 1.0 na serveru dostupne, aplikace se nepripoji.

Ze prej windows a bezpecnost ... lol.

Začít dělat nový kernel v Rustu přece lze i tak, že forknu stávající jádro a ten Rust tam budu přidávat tak, jak se snaží ti,co to tam chtějí.

Do jaké míry budou udržovat kompatibilitu s původním nerustovým jádrem bude jejich věc.

Lidi obvykle nechtějí tříštit síly. Je lepší se domluvit, a dělat to najednou. Fork je zbytečně na sílu.

V tomto případě by fork byl tou domluvou a nikoliv tříštěním sil.

Dalo by se to udělat i jako větev v rámci jednoho git repozitáře.

Prostě mám jednu větev bez Rustu.

V druhé implementuju Rust a zároveň sleduju změny v původní, master větvi a buď je přijmu, nebo je vyřeším s ohledme na už hotovou implementaci Rustu

rust resi hlavne smart pointery a alokaci, je s tim problem v kernelu, namyslim. nechci rust v kernelu. radsi bych alternativni kernel v rustu a gnu userspace. je snad rust kernel lepsi napad nez hurd kernel? neni.

> je snad rust kernel lepsi napad nez hurd kernel?
Rust kernel je o volbě jazyka. Hurd kernel je o volbě architektury kernelu. To nejde porovnávat.

Pro Linux se používá C a ne C++ (přesněji C++ oškubané na úroveň C), protože Linus argumentoval, že C++ je složitější, pomalejší, nepřehlednější, nepředvídatelnější.
Rust je na úrovni C s tím, že přidává výhody v pohodlnosti moderních jazyků, aniž by byl pomalejší, nepřehlednější a nepředvídatelnější. Tudíž Rust dává dobrý smysl.

Taky pro C má Linux spoustu toolů kontrolujících kód, pro C++ by všechny ty tooly museli znovu napsat, ale Rust dovolili, protože ty kontroly (většinu) má jazyk přímo v sobě.

A co se týče nepřehlednosti C++, tam Linus argumentoval tím, že když kouká na změnu, tak chápe, co to dělá. Kdežto u C++ by musel do hlavy načíst i okolní kód, protože spousta funkčnosti je schovaná (výjimky, přetížené operátory, ...).

2. 9. 2024, 10:35 editováno autorem komentáře

On s Rustem v kernelu je hlavně problém, že Rust si ještě neřekl, jaký vlastně je jeho paměťový model vzhledem k věcem typu přeskládávání instrukcí a viditelnost téhož z jiných CPU (třeba rcu_dereference() a vlastně celé RCU), paralelní přístup k paměti ze strany CPU i periferií (různé ty kruhové buffery a mailboxy pro komunikaci s protistranou jako má třeba virtio), a tak podobně. A nejen že si neřekl, ale někteří propagátoři Rustu v kernelu vlastně ani nevědí, že toto je nějaký problém k řešení.

Víc než jste o tom kdy chtěli vědět lze najít například v blogu Paula McKenneyho, autora RCU:
https://paulmck.livejournal.com/tag/rust

2. 9. 2024, 10:27 editováno autorem komentáře

Opravil bych jen čas: tohle bude naprosto zásadní problém, pokud se má rust v jádrře opravdu nějak víc rozšířit. Zatím se spíš omezují na nějaké "leaf" drivery, takže na větší problémy tohoto typu ještě nenarazili a vystačí s jednoduchým modelem, že jakýkoli paralelní přístup je špatně a chytrý překladač se postará, abychom ho vyloučili. A nebo když už je potřeba pracovat s něčím, co používá RCU nebo jinou "lockless" synchronizaci, přistupuje se k tomu přes céčkové wrappery, čímž se to stane PNJ. (A všetečným otázkám, jak že pak rust vlastně zaručuje tu memory safety, se raději vyhneme.)

Jako jo, ale ten budoucí čas už je "fakt brzo" - v článku se zmiňuje Asahi Lina a driver pro applovskou GPU. To už víceméně je ten problém kruhových bufferů s přístupem "z obou stran north bridge". Částečně z toho lze udělat PNJ ještě tím, že se ty buffery dají do paměti GPU, která je přes něco jako MTRR v CPU nakonfigurovaná jako necachovatelná a bez write-combing, ale umístění v hlavní paměti se stejně časem nevyhnou.

Ona ta cachovatelnost je docela rozdil mezi platformama.. napr stridat ARM vs X86, tak si musite v driveru hodne ohlidat, ze chcete opravdu onen koherentni pool (necachovanou oblast). Na jedne z platforem ale bude fungovat i cachovana, protoze struktura caches je jina a dokud to nezkusite portovat jinam, tak nevidite, ze mate problem, protoze zdanlive vse funguje.

A nekde jde udelat cache flush, a nekde udelat nejde. Nekde flush znamena dropnout celou cache, nekde jen dotcene radky - tahle nekonzistentnost je nejvetsi pitomost prozatim v Linuxu, kdyz resite low level veci, ale oni na to nemaj konzistentni API.

Prakticky napr nas DMA driver pouziva oba typy alokaci - koherentni region (s marnym vykonem) obsahuje jen deskriptory ktere je nutno menit pri linkovani bufferu runtime, a obycejne alokace pro vsechny ostatni - staticky inicializovane a pozdeji nemenne deskriptory.

(už trochu off-topic, ale představte si, že bývaly platformy typu sun4m, které měly _virtuálně_ adresovanou cache, tedy umístěnou ještě před TLB. Pak systém musel řešit i případy, že je toho třeba vylít víc v případě, kdy tatáž fyzická stránka je do virtuální paměti mapovaná víckrát)

napr stridat ARM vs X86

A to jsou pořád ještě docela "civilizované" architektury. Ale co si vzpomínám, tak třeba Alpha sloužívala jako spolehlivý generátor protipříkladů k "samozřejmým" očekáváním.

Ono to může být tak, že jsme nedaleko bodu zvratu, a brzy o Rustu v Linuxu nebudou tak velké pochyby.

Ale jsou tu další věci, které chci zmínit. Rust vyžaduje, více než kterýkoliv jiný programovací jazyk změnu myšlení programátora, a přitom nemohu najít česky psanou knihu o programování v něm.

Chápu, že tu je několik zdrojů, včetně toho na Root.cz , ale to mi nestačí, chtělo by to ještě ten papír, případně případy o základních konstrukcích GoF v Rustu.

on je to trošku moc pohyblivý cíl + malá cílovka, aby do toho vydavatel šel. Autor klidně, ale někdo to musí vydat, zajistit distribuci a tak.

Nejen že je cílovka relativně malá, ale z toho zbytku bude ještě míň lidí kteří by upřednostnili českou knihu, když je zbytek zdrojů v angličtině. I na pražských Rust meetupech je angličtina primární jazyk přednášek.

Snad se to pohne s podporou Rustu v GCC.

Možná by bylo fajn, kdyby do budoucna šlo Rust mixovat s C, podobně jako to má Mac se Swingem, a teprve později přejit na Rust.

Do interop se teď investuje ze všech stran - spousta velkých firem na přechod na Rust dost sází, ale přepsat celou codebase najednou není příliš realistické.

Konkrétně s C už je to v pohodě (I když GCCrs bude super), dost lidí už píše Rust moduly pro Python, jen C++ je pokud vím pořád celkem problém z důvodu rozdílů obou jazyků.

To je zajímavé, to by GCCrs (GCC Rust) možná mohl překládat dohromady jak Rust, tak C, včetně odchytávání vzájemných kooperačních problémů..

Jak píši dříve, moc to nevypadá, peníze jdou především na PR vlny
https://www.root.cz/clanky/kernel-panic-s-qr-v-linuxu-6-12-neshody-rust-vyvojaru-se-spravci-casti-jadra/nazory/1156599/