Vlákno názorů k článku Kernel panic s QR v Linuxu 6.12, neshody Rust vývojářů se správci částí jádra od David Heidelberg - Ono to není tak černobílé. Doporučuji si přečíst odkazovaný...

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.