Non essendo ferratissimo sulle CPU ho sempre interpretato Big Endian – e la sua controparte Little Endian – come componenti che in qualche modo “facevano funzionare parte dell’ingranaggio che si muove all’interno dei circuiti“, una frase che si potrebbe riformulare in “non mi sono mai posto il problema“.

Poi però è arrivato Linus, e quando parla, anzi, quando si arrabbia Linus, è bene approfondire. Così, ecco intanto una spiegazione su cosa siano le due componenti citate in apertura, che riguardano come un processore memorizza i dati in memoria.

• In Little Endian (LE) il byte meno significativo di un numero viene salvato all’indirizzo di memoria più basso, e questo è lo standard de facto di oggi, utilizzato da Intel x86, ARM in quasi tutte le implementazioni, e anche RISC-V.
• In Big Endian (BE) il byte più significativo va all’indirizzo più basso, ed è una modalità comune ai mainframe IBM ed alcune architetture RISC (SPARC, MIPS, PowerPC).

Per farla breve, dato il numero esadecimale 0x12345678, Little Endian memorizzerà 78 56 34 12, mentre Big Endian memorizzerà 12 34 56 78.

Essendo il mondo di oggi standardizzato sul Little Endian, e i problemi di interoperabilità si risolvono con istruzioni dedicate o librerie, non c’è quindi bisogno di architetture Big Endian.

Ora, se come chi scrive, non vi siete mai posti il problema, sappiate che è del tutto normale: l’endianness è un dettaglio architetturale (come il set di registri o le istruzioni della CPU) e quindi riguarda chi scrive il Kernel, driver, compilatori o librerie di basso livello. L’unico momento in cui queste cose potrebbero avere un impatto nel quotidiano di un sysadmin della strada è quando c’è incompatibilità di binari: se un software compilato per Little Endian viene fatto girare su una CPU Big Endian, non va.

Ma siccome il mondo è ormai Little Endian, questo rischio è accademico.

Tornando però a chi si preoccupa di queste cose, e nello specifico al Kernel Linux, ecco arrivare il vero motivo di questa notizia: i lettori rimarranno esterrefatti, ma Linus Torvalds si è arrabbiato.

Rispondendo ad una domanda dell’ingegnere Ben Dooks, il quale chiedeva se ci fosse qualche possibilità di vedere incluso prima o poi nel Kernel Linux il lavoro che lui ed il suo team avevano fatto su Big Endian in RISC-V, la risposta placida di Torvalds è stata:

Oh Christ. Is somebody seriously working on BE support in 2025?
WHY?
Seriously, that sounds like just *stupid*. Is there some actual real reason for this, or is it more of the "RISC-V is used in academic design classes and so people just want to do endianness for academic reasons"?

Oh Cristo. C’è davvero qualcuno che sta seriamente lavorando sul supporto BE nel 2025?
Perché?
Davvero, questa cosa sembra semplicemente *stupida*. Esiste una qualche ragione reale per questo, oppure è una roba del tipo “RISC-V è utilizzato nelle classi di design accademiche e quindi le persone vogliono lavorare intorno all’endianess per ragioni accademiche?

Il messaggio prosegue poi con una serie di rilevanze oggettive sul tema che sono indubbiamente valide, ma il senso è racchiuso in quelle prime righe (se volete un recap completo questo articolo di Phoronix vi sarà di aiuto): di fatto si tratta di un “bluff” che serve unicamente per inserire nel Kernel elementi che aiutino solo a fini accademici.

La questione è talmente chiara che Linus, inaspettatamente, subito dopo invia un nuovo messaggio nel quale spiega come la richiesta (ed il lavoro dietro ad essa) sia del tutto insensata, almeno a suo dire.

In conclusione ecco riportate due frasi che riassumono il senso delle discussioni che si potrebbero trarre da questa vicenda, la prima è:

RISC-V is enough of a mess with the millions of silly configuration issues already. Don't make it even worse.
Tell people to just talk to their therapists instead.  That's *much* more productive.
Really.

RISC-V è già un macello con già milioni di tristissime issue di configurazione. Non rendere le cose peggiori.
Dì alle persone [che hanno sviluppato quel codice] di andare a parlare con il loro terapista. Quello è *molto* più produttivo.
Davvero.

Con buona pace di tutte le menate che solamente ieri ci siamo posti sui Code of Conduct.

La seconda frase, che chiude, almeno lato Torvalds, la questione, è invece relativa alla posizione mantenuta dal creatore di Linux che, al solito, è difficilmente attaccabile:

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.

La mainline del Kernel è per lo sviluppo della mainline. Non per esperimenti casuali che rendono il mondo un posto peggiore.
E sì, siamo open-source, e questo significa chiaramente che chiunque è più che il benvenuto nel provare a contraddirmi.

Con buona pace del povero Dooks, il quale, in risposta all’attacco di Torvalds, ha chiuso il thread affermando di voler vestire con grande orgoglio il marchio “Sono stato menato da Linus e sono sopravvissuto“.

Siamo tutti con te Ben!