Názory k článku
Další síťová karta bude mít jaderný ovladač v Rustu

Neplest MAC a PHY.
PHY ovladac je primitivni (a ten odkazovany super primitivni). Jen prace s par registry.
Zajimave by bylo, pokud by to byl ovladac cele karty - DMA a IRQ, zero copy.

2. 9. 2024, 16:52 editováno autorem komentáře

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

A cim ze se meri uspech? Poctem radku v diffu?

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.

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?)

Celých 19 let jsi to nenapsal v C, tak co jim zbylo. Chápeš vůbec, že nikdo nikomu nebrání používat v jádru C, že jo? Že jo?!


// TODO: sleep here until the hw becomes ready.
Ok(())


No bomba. Jsem si jistý, že všechny pull requesty v C jsou ryzí zlato.

Maličko rozdílná situace. Představte si rustové pull requesty z pohledu jádra jako nového seniora, který na pohovoru nasliboval modré z nebe, ve zkušebce.

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é?

Njn, proto to musí být memory safe. Aby to šlo prasit bez přemýšlení.

No jestli si myslíte, že v memory safe jazycích se dá prasit bez přemýšlení, tak mám špatnou zprávu.

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...

Na Ruste je nieco hnile.
Nie je mozne, aby (re)kompilacia samotneho prostredia vyzadovala 20GB disk space a take kvanta CPU.
Low level ovladace ? Preco preboha.

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č.

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.

> Přináší výrazně pohodlnější a modernější koncepty než aktuální mainstraim (C#, Java).

S tymto absolutne nesuhlasim. Ja som Rust opustil v prospech C# prave pre to, ze C# je vyrazne pohodlnejsi, je velmi moderny a vykonostne je to skoro to iste ako Rust.