A Linux 6.17 fejlesztési ciklusában komoly vitát kavart, hogy Linus Torvalds elutasította a RISC-V architektúrához kapcsolódó változtatásokat. A döntés oka egyrészt az volt, hogy a kódot túl későn küldték be a merge window végén, másrészt pedig Torvalds szerint több, nem RISC-V-specifikus, ráadásul rossz minőségű elem is bekerült a javaslatba. A fejlesztőknek így legkorábban a 6.18-as verzióban lesz lehetőségük újra próbálkozni – de szigorúbb feltételek mellett.

A visszautasítás oka

A RISC-V fejlesztői a 6.17-es kernel merge window utolsó napjaiban nyújtották be a frissítési csomagot, ami többek között az alábbi funkciókat tartalmazta:

• RISC-V IOMMU támogatás ACPI-alapú rendszerekhez
• ACPI BGRT támogatás a gyártói logók bootolás közbeni megjelenítéséhez
• Hibajavítási megoldások (errata workarounds)
• Xmipsexectl kiterjesztés támogatása
• MMU típusának beolvasása Device Tree-ből
• Teljesítményjavítások az endian konverziós rutinokban
• Kprobetrace támogatás
• MPXY és RPMI SBI kiterjesztések
• Control-Flow Integrity támogatás felhasználói térben futó folyamatokhoz

Bár ezek önmagukban hasznos fejlesztések, Torvalds szerint a csomagban több olyan elem is szerepelt, amely nem volt RISC-V specifikus, és ráadásul általános kernel fejlécekbe (generic header files) került be, ezzel rontva a kód minőségét és érthetőségét.

Torvalds kemény kritikája

A levelezőlistán Torvalds egy konkrét példát is kiemelt:
A make_u32_from_two_u16() nevű segédfüggvény szerinte „haszontalan szemét”, amely rontja a kód olvashatóságát. Torvalds úgy érvelt, hogy a kifejezés egyszerűen leírható lenne például (a << 16) + b formában, amely egyértelműen mutatja a művelet logikáját. A segédfüggvény ezzel szemben eltakarja a működést, és bizonytalanságot okoz a bájtsorrend értelmezésében.

Torvalds üzenetének lényege:

• Nincs helye nem RISC-V specifikus kódnak a RISC-V patchben
• Nem lehet általános kernel fejléceket „szeméttel” szennyezni
• Nem elfogadható a merge window vége felé nagy, vitatható tartalmú patch-et küldeni

Következmények

A RISC-V változtatások így nem kerültek be a 6.17-es verzióba, a fejlesztőknek legkorábban a 6.18-as kernel fejlesztési ciklusának elején nyílik új esélyük. Torvalds hangsúlyozta, hogy a következő próbálkozásnak:

• időben kell érkeznie,
• ne legyen benne nem releváns és gyenge minőségű kód.