Linus Torvalds ismét határozottan hallatta a hangját a Linux kernel fejlesztésével kapcsolatban, ezúttal a RISC-V architektúra big endian támogatásának ötlete kapcsán. A levelezőlistán felmerült kérdésre, miszerint a big endian patchek bekerülhetnek-e a jelenlegi kernelciklusba, Torvalds élesen reagált. Véleménye szerint teljesen értelmetlen 2025-ben big endian módot bevezetni a RISC-V-re, hiszen semmilyen gyakorlati haszna nincs, csupán akadémiai játszadozásnak tűnik. Úgy fogalmazott, hogy a RISC-V már most is elég nagy káosszal küzd a rengeteg konfigurációs lehetőség miatt, és egy új endianness bevezetése csak tovább rontaná a helyzetet. Ezt válaszolta Linus:
„Ó, Istenem. Valaki tényleg big endian támogatáson dolgozik 2025-ben?
MIÉRT?
Ez egyszerűen butaság. Van erre valós indok, vagy csak akadémiai játék, mert a RISC-V-et úgyis oktatásban használják?”
A big endian támogatás melletti hivatalos indoklást Torvalds különösen bírálta. A RISC-V közösség egyes tagjai azzal érveltek, hogy az internetprotokollok big endian sorrendet használnak, ezért a little endian rendszereknek byte-swapping műveleteket kell végezniük, ami teljesítményveszteséget okozhat. Emellett az is felmerült, hogy egyes RISC-V implementációk nem tartalmazzák a Zbb kiterjesztést, amely hatékonyabbá tehetné a byte-kezelést. Torvalds szerint azonban mindez hibás érvelés. A hálózati bytecserék költsége elhanyagolható, a valódi teljesítményproblémák a memória-alrendszerben jelentkeznek. Ha pedig tényleg gondot okoz a byte-kezelés, akkor a megoldás nem egy új big endian mód bevezetése, hanem a Zbb kiterjesztés implementálása lenne.
A kernel fejlesztője nyíltan kimondta, hogy szerinte ez az irány „őrültség”, és csak ártana a RISC-V ökoszisztémának. Úgy véli, a big endian támogatás nem oldana meg semmilyen valós problémát, ellenben újabb fragmentációt okozna, amely hosszú távon gyengítené a RISC-V pozícióját. Bár elismerte, hogy egyes előzetes big endian patchek, például a CONFIG_CPU_BIG_ENDIAN, már megjelentek a kódban, hangsúlyozta, hogy a mainline kernel nem kísérleti terep, hanem széles körben használt, releváns funkciók gyűjtőhelye.
Torvalds zárásként leszögezte, hogy a Linux közösség csak akkor foglalkozhat komolyan a big endian RISC-V támogatásával, ha az a jövőben valóban elterjedt és iparilag is szükséges megoldássá válik. Addig azonban nem kívánják aktívan elősegíteni egy olyan fejlesztés terjedését, amely szerinte inkább hátráltatja, mint előreviszi a RISC-V-et. Ez az álláspont jól mutatja, hogy a Linux fejlesztése során a gyakorlati szempontok és a hosszú távú stabilitás fontosabbak a kísérleti jellegű ötleteknél, még akkor is, ha azok mögött egyes fejlesztői körök lelkesedése áll.
Oké, most rákerestem erre, és most határozottan leszögezem:
NEM FOGUNK ELŐRE BIG-ENDIAN TÁMOGATÁST ADNI RISC-V-RE.
Az erre a képtelenségre dokumentált „indoklás” annyira ostoba, hogy szavak sincsenek rá. De mivel a riscv.org mégiscsak szavakba öntötte, idézem őket:
„Még mindig vannak olyan alkalmazások, ahol számít, hogyan van tárolva az adat, például az interneten áthaladó adatokat továbbító protokollok, amelyek big-endian módon vannak definiálva. Így amikor egy little-endian rendszernek meg kell vizsgálnia vagy módosítania kell egy hálózati csomagot, át kell alakítania a big-endian értékeket little-endianné és vissza, ami egy olyan RISC-V célplatformon, amely nem valósítja meg a Zbb kiterjesztést, akár 10–20 utasítást is igénybe vehet.”
Más szóval, azt sugallják, hogy a RISC-V-hez big-endian módot kellene adni a következő okokból:
(a) internetes protokollok – ahol a bájtcsere egyáltalán nem probléma
(b) „néhány RISC-V implementáció nem támogatja a meglévő Zbb kiterjesztést” mint kifogás
Ez kész őrület. Először is, még ha a bájtcsere valóban költséget jelentene a hálózati működésben – nem az, a valódi költségek általában a memóriarendszerekben vannak – akkor is csak annyit kellene tenni, hogy megvalósítják végre a Zbb kiterjesztést.
Ne gyertek azzal, hogy „annyira alkalmatlanok vagyunk a Zbb implementálására, hogy most inkább azt kérjük, hogy MINDENKI MÁS szenvedjen egy sokkal rosszabb kiterjesztéstől, és tovább daraboljuk a RISC-V-et”.
Remélem, ez csak valami áprilisi tréfa, de az az oldal „2025. március 10.” dátummal szerepel. Közel van, de nem elég közel.
Ez az a fajta ostobaság, ami egyszerűen csak rossz fényben tünteti fel a RISC-V-et.
Ben – attól tartok, hogy azon az oldalon a „további olvasnivalók” a Codethinkhez mutatnak.
Látom, hogy néhány CONFIG_CPU_BIG_ENDIAN már bekerült, de ennek most azonnal meg kell állnia.
A fővonalbeli kernel a fővonalbeli fejlesztésért van. Nem véletlenszerű kísérletekért, amelyek rosszabb hellyé teszik a világot.
És igen, nyílt forráskódúak vagyunk, ami nagyon is azt jelenti, hogy bárki szívesen bizonyíthatja, hogy nincs igazam.
Ha kiderül, hogy a BE RISC-V valóban létező és releváns dolog lesz, és ténylegesen helyet talál a RISC-V ökoszisztémában, akkor természetesen támogatnunk kell majd a fővonalbeli kernelben is.
De tényleg úgy gondolom, hogy ez valójában csak rosszabbá teszi a RISC-V-et, és hogy nem szabad aktívan segítenünk a további széttagolódást.
Eredetileg így:
Ok, I just googled this, and I am putting my foot down: WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V The documented "reasoning" for that craziness is too stupid for words, but since riscv.org did put it in words, I'll just quote those words here: "There are still applications where the way data is stored matters, such as the protocols that move data across the Internet, which are defined as big-endian. So when a little-endian system needs to inspect or modify a network packet, it has to swap the big-endian values to little-endian and back, a process that can take as many as 10-20 instructions on a RISC-V target which doesn’t implement the Zbb extension" In other words, it is suggesting that RISC-V add a big-endian mode due to (a) internet protocols - where byte swapping is not an issue (b) using "some RISC-V implementations don't do the existing Zbb extension" as an excuse This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension. Don't go "we're too incompetent to implement Zbb, so we're now asking that EVERYBODY ELSE feel the pain of a much *worse* extension and fragmenting RISC-V further". I'm hoping this is some April fools joke, but that page is dated "March 10, 2025". Close, but not close enough. This is the kind of silly stuff that just makes RISC-V look bad. Ben - I'm afraid that that page has "further reading" pointing to codethink. I see some CONFIG_CPU_BIG_ENDIAN has already made it in, but this needs to stop. The mainline kernel is for mainline development. Not for random experiments that make the world a worse place. And yes, we're open source, and that very much means that anybody is more than welcome to try to prove me wrong. If it turns out that BE RISC-V becomes a real thing that is relevant and actually finds a place in the RISC-V ecosystem, then _of_course_ we should support it at that point in the mainline kernel. But I really do think that it actually makes RISC-V only worse, and that we should *not* actively help the fragmentation.
