Vím, že se tato změna netýká stávajících LTS větví (např. 6.1 nebo 6.12) a že k odstranění podpory dojde až v některé z budoucích hlavních verzí řady 7.x.
I tak vypuštění podpory pro STM32 s jádry Cortex-M4 a Cortex-M7 mě bude pravděpodobně mrzet nejvíce. Je sice potřeba mít na paměti, že se jedná o systémy bez MMU, které využívají uClinux a statický spustitelný formát bFLT namísto ELF, takže nabídka dostupných balíčků je poměrně omezená (není k dispozici syscall fork()). Přesto však kernel poskytuje zajímavé možnosti, například práci se souborovými systémy EXT2, EXT3, EXT4 nebo NTFS, aniž by bylo nutné skládat řešení z několika samostatných open-source knihoven a RTOS. Vše je tak dostupné v rámci jednoho uceleného prostředí.
Nezbývá tedy nic jiného než provést fork a udržovat si vlastní větev kernelu. Ostatně stejně jsem musel postupovat i v případě podpory FPU pro Cortex-M7, která se nikdy nedostala do hlavní větve linuxového kernelu - jde o backport z Emcraft Linuxu v2.6.33 do v6.1.x.
V tomto smeru me napadlo uz nekolikrat udelat "novej linux" - vzit jenom ty drivery ktere potrebuji, a udelat jim sandbox / wrapper, tj. nektere subsystemy zcela nahradit vlastni implementaci.
Bohuzel ale nestabilita vnitrniho API by znamenana, ze to nepujde udrzovat a clovek se zasekne na nejake stare / derave / zabugovane verzi, a celou instrumentaci muze delat odznova.
Jedine uzivatele.
Zadny vyrobce neudrzuje EOL veci. Proto treba mizi stare grafiky, procesory, atd.
Linux uz davno neni "because you can", ale dalsi komercni chapadlo, jestli se vubec nekdo angazuje.
Toto zneje do znacnej miery ako mocenie proti vetru. Pride mi ako znacne menej roboty proste podporu ext-u do RTOS dotlacit raz a mat ju tam, nez udrziavat nepodporovany kernel na nepodporovanej architekture.
Zvlast s tym FPU, ktore je prakticky v kazdom RTOS podporovane nativne.