Téměř před rokem se v jádře 6.8 objevil první ovladač napsaný v Rustu. Šlo o síťovou kartu Asix AX88796B. Do jádra 6.12 se chystá další ovladač a je to opět síťová karta.
Jde o Applied Micro Circuits Corporation QT2025 PHY. Fujita Tomonori poslal ovladač minulý týden. Je jako předchozí založen na ovladači v C pro čip TN40×x. Ten však umí více PHY. Ovladač byl testován na síťové kartě Edimax EN-9320SFP+ 10G.
(zdroj: phoronix)
Ufff, tak jsem jsem udělal tu chybu a ten diff si rozkliknul.
Tohle jako vážně je presentováno jako úspěch v Rustu? A pak se Rustaři divěj, že je nikdo nebere vážně. Viz též https://www.root.cz/clanky/kernel-panic-s-qr-v-linuxu-6-12-neshody-rust-vyvojaru-se-spravci-casti-jadra/
Edit: A co přidat nějaký ten volání hello_kernel() jako volání printk() coby monáda v Haskelu? Ten první řádek v dmesg "Linux version blabla" by se na to hezky hodil...
2. 9. 2024, 21:13 editováno autorem komentáře
Napriklad mirou semanticnosti.
To je vec, ktera ma rozsah od nedokumentovaneho blobu, po kod strukturovany tak, aby sla nastavit v budoucnu vec, kterou puvodni autor nemenil. Takze namisto zapisu magickych inline hodnot do random registru, udelate definici a pojmenovani registru i bitu, a pak pripadne funkce (interni api) ktere nastavi slozitejsi veci.
Vzhledem k tomu, že část tohoto je asi produktem reverse engineeringu, tak se semantické definice píšou hůř.
Soudím dle:
// The following writes use standardized registers (3.38 through
// 3.41 5/10/25GBASE-R PCS test pattern seed B) for something else.
// We don't know what.
V C by to vypadalo podobně, ale na víc řádků.
Nicméně třeba error handling těch write a probe je tady mnohem kratší, než by byl v čistém C. Každý jeden otazník by byl if a goto error nebo tak něco.
Ano, tahle cast neni v datasheetu, ale obvod to je 10G only, tak nevim proc to komentuje s 5 a 25G. Nejspis by to fungovalo i bez toho.
A datasheet ukazuje jak se PHY ma nahodit - uvedeny kod je total spatne. Pusti mcu z resetu a pak mu pod rukama prepise FW v sram.. meh.
DS jasne indikuje: natlac tam FW1, FW2, pak pust mcu z resetu:
https://imgur.com/R8fIaCJ
Kod, ktery autor driveru prezentuje je proste hnuj.
Ano, tahle cast neni v datasheetu, ale obvod to je 10G only, tak nevim proc to komentuje s 5 a 25G. Nejspis by to fungovalo i bez toho.
To spíš bude jen nějaký další projev "neznalosti". Ty dataraty jsou 2.5G/5G/10G a někdo z toho udělal 25G.
Tak to je možná právě ono. Rust preprocesor nemá, a to je dobře. Ten má buď konstanty, nebo plnohodnotná makra.
Vzhledem k tomu, jak neprošlapaná je to cesta použití Rustu v jádře, se nedivím, že používají spíše konzervativnější konstrukce. Věřím, že v budoucnu se usadí různý osvědčené postupy. Ale postupně.
Ostatně jaký lepší důkaz, že je to dobrá strategie, než skutečnost, jak je tu poukazováno na preprocesor Cčka.
Slusnej bizar... na podporu primitivni komponenty z roku 2005 cekalo Linuxove jadro 20 let - protoze hipsta decka bez Rustu uz ani neumi zapsat deset registru a jeden firmware :D
PS: Jake prase napise driver s binarnima hodnotama registru (a pak to komentuje nazvem bitu?). Tohle nemuze projit.. nebo rust neumi #define konstanty? (a kdyz uz jsme u toho - ma Rust nejakou vyssi schopnost pracovat s bitfieldy, abych nemusel delat tri #define pro OFFS, SIZE, MASK a pak jeste mit dalsi makra na read/write?)
Nejlepsi jsou ovsem komenty na tema neco nekam zapisuju a nevim vlastne proc a co to dela ... coz ovsem naprosto 100% vystihuje vsechny rusisty.
O mnohem pak vypovida i to, ze gentoo ti predhodi binarku, protoze zkompilovat to samo sebe neumi. Naprosto nechapu jak moh nekdo pripustit vubec i jen jedinej radek v kernelu.
A nejsou takových věcí OSS drivery plné, protože bez znalosti HW a zdrojáků firmware kolikrát nezbývá nic jiného než sledovat co dělá uzavřený driver a dělat to samé?
Přesně tak. Naopak v Rustu musím mít model hodně dobře promyšlený, jinak se zaseknu v borroweru. Obvykle je kompilovatelné řešení správně z logiky vlastnictví dat a každé oprava kompilační chyby je obvykle směrem k čistějšímu modelu. Naopak v Cčku mohu data naalokovat kdekoliv a pak se divím, kde všude mi to vykvete...
Ale samozřejmě, že to je možné. Když může hloupá malá webová stránka stahovat gigabyte javascriptových zdrojáků.
V Rustu ty inference a borrow checker nejsou zadarmo, za ty kontroly se platí strojovým časem při překladu. Existoval i hodně přísný překladač Cčka a překvapivě byl mnohem pomalejší než gcc.
Strojový kód se nemusí překládat vůbec. ASM jen malinko. Cčko už něco potřebuje, C++ se šablonami a STL trvá a Rust je ohledně kontrol ještě přísnější.
Každá úroveň abstrakce a kontrol ten překlad zesložiťuje.
Pamatuju Java server s GWT, nestačilo tomu pro překlad 10 GB RAM a úplně to vytížilo desktopový Xeon (nějaký Dell desktop z doby před 10 lety).
Já v Rustu napsal komplet run-to-completion runtime a radiový stack pro embedded mikrokontroler. Maličké STM32 se 32K FLASH a 8K RAM. A to samé i v C++ (bez výjimek). Ten Rust byl nakonec hezčí a lépe udržovatelný, ale možná spíš proto, že C++ dovolilo některé "nebezpečné" operace a pro Rust jsem musel mnohem víc dbát na správné interní členění a správnou abstrakci nad unsafe bloky.
V Rustu ty inference a borrow checker nejsou zadarmo, za ty kontroly se platí strojovým časem při překladu.
Podobné typy jako má Rust zvládl kompilátor jazyka ATS (Applied Type System), překládat rychleji. A i výsledný kód byl rychlejší (protože na rozdíl od Rustu nebylo třeba nic kontrolovat za běhu - např. indexy do pole).
To by mě zajímalo, jak se řeší indexy do pole, když je to pole plněné dynamicky a indexy mohou být vzaty v podstatě odkudkoli. Jazyk, kde není třeba nic kontrolovat za běhu, je dost nepraktický, ne? Jinak vždy, když vidím nějaký podobný akademický superjazyk, který dává na zadek nějakému jazyku z praxe, říkám si, proč tedy všichni nepoužíváme ten superjazyk.
To by mě zajímalo, jak se řeší indexy do pole, když je to pole plněné dynamicky a indexy mohou být vzaty v podstatě odkudkoli.
Funkce jsou schopny přijmout "důkazy" (vhodné typy). Například funkce pro indexování pole
fun{a:t@ype}
indexuj_pole
{n:int}{i:nat | i < n} (A: arrayref(a, n), i: size_t i): (a)
má dva normální parametry v kulatých závorkách A (pole s prvky typu a o délce n) a i (index do pole, který má hodnotu typového parametru i).
Pak ale potřebuje dva typové parametry. První typový parametr n s velikostí pole. Druhý i s velikostí indexu a omezením jeho velikosti.
Konkrétní hodnoty n a i nemusí být známy v době kompilace. V době kompilace se jen ověří, že to jsou čísla, a že i má požadovaný rozsah.
Jinak vždy, když vidím nějaký podobný akademický superjazyk, který dává na zadek nějakému jazyku z praxe, říkám si, proč tedy všichni nepoužíváme ten superjazyk.
To je dobrá otázka. V tomhle by asi také šlo psát jádro.
Osobně si myslím, že je to jazyk z rodiny Standard ML, která není moc oblíbená. Ale nevím proč.
Některé problémy podobného charakteru se v Rustu dají řešit pomocí const generics. Další pattern pro compile-time garance něčeho co se obvykle řeší runtime, který je v Rustu jako doma, jsou typestates.
Přesně tak, tohle v embedded Rustu dělám pořád. Const generics a pole statické velikosti (plus https://docs.rs/heapless/latest/heapless/).
A dělal jsem to i v C++ (www.etlcpp.com má klasické STL kontejnery se statickou velikostí jestli neznáte).
A runtime checking vypnutý co nejvíce to jde, protože na mikrokontroleru nedává smysl.
Tak zrovna tenhle příklad není moc přesvědčivý. Vlastně to dělá +- to samé jako třeba SAL anotace v Cčku. Jen je to teda pro náhodného kolemjdoucího podstatně složitější na pochopení.
A tu kontrolu na rozsah pole to jen vyšoupne ven, kde nějak (zajímavá otázka je jak) musím říct překladači že to pole a ten index, které přišly z různých míst patří dokupy.
Děkuji za tip na zajímavý jazyk.
Každopádně nepřijde mi to moc k tématu. Rust je jazyk, kterému se podařilo etablovat na konkrétní niku. Dělá věci výrazně líp než starousedlíci (C, C++). Přináší výrazně pohodlnější a modernější koncepty než aktuální mainstraim (C#, Java). A hlavně funguje!
Nikdo ale netvrdil, že je to topka (Haskell, Idris). Ve skutečnosti fakt, že to není jen lepší jak C, ale dokonce o tolik lepší, přináší určité lidské potíže.
