Folytatódik a lomtalanítás a Linux kernelben - DEC Alpha EV5, PowerPC 40x

Kernel

Úgy fest, hogy a 6.10-es Linux kernel kiadásával búcsúzik több régi platform támogatása:

( crown v | 2024. 05. 07., k – 13:46 )

Szerkesztve: 2024. 05. 07., k – 13:49

ahogy nezem, power architektura atment a power.org hataskorebe, ami kb elhalt. ezt az osregi verziot en is dobtam volna a linux helyeben.

más nem gyárt Power ISA-val processzort

Dehogy nem, az NXP (az általuk megvett Freescale nyomán, ami meg a Motorola Semiconductors átnevezett/függetlenedett verziója volt). Mondjuk a többségét gondolom mihelyst lejárnak a hosszútávú support szerződések, dobják... De a 40x az amúgy egy embedded IBM mag volt, amit licencben még az AMCC gyártott, asszem. Nagyon low-end, no FPU és az MMU-ja is igen csak kezdetleges (ha egyáltalán volt) ami miatt elég sok külön codepath volt rá a kernelben, miközben sosem volt egy igazán népszerű mag, gondolom. Vagy nem olyasmi, amire manapság modern kernelt akarnak rakni (set-top-boxokat, hálókártyákat, ilyesmiket hajtott, rendszermanagement processzorként is használták, stb). Amúgy ehhez hasonlóan az ős-PowerPC 601-et is szintén a "specialitásai" miatt raktak ki pár éve.

Gondolom a 440-es sorozatra, ami a 400-asok "nagytesója", és van benne FPU meg rendes MMU az eltávolítás nem vonatkozik, de ezt nem néztem meg.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Én tudom. :) Asszem annyi a "probléma" mindössze, hogy ezek mind big-endian only chipek - ha jól tudom, legalábbis a hozzájuk adott ökoszisztéma/SDK pár éve még BE only volt, mostanában nem néztem -, és az NXP nem is ugrál hogy PPC64LE-t csináljon hozzájuk, amivel csak az a gixer, hogy egy rakás FOSS projektet meg az IBM tart karban akik meg erőből tolnak mindent a little endian felé... Az NXP amúgy is hajlamos "egy bizonyos" verziót, vagy custom tree-t szállítani bootloaderből, kernelből, driverekből a chipjeihez, aztán ez van, osszad be... Ha van elég igény, akkor előbb-utóbb lesz persze mainline support is, pl. az iMX ARM SoC chipekhez is lett lassan-lassan... De sok sikert hivatalos supportot kapni, ha nem az NXP-féle tree-t használod. Legalábbis 4-5 éve még így volt. Mostanában kimaradtam ezekből kicsit.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Nekem nincs velük tapasztalatom, meg nem használok ilyeneket, így nem fog hiányozni, de elvi síkon nem támogatom, hogy funkciókat vegyenek ki, ezt ráadásul újabban feature-ként reklámozzák, harangozzák be a soydevek, akiknek újabban most ez a mániájuk, hogy miden legyen mesterségesen elavultatva, támogatása megvonva, nyírjuk ki, stb.. A Phoronix írta, hogy mindezzel csak kb. 4400 sornyi kódtól szabadulnak meg, hát az kb. semmi a Linux kernel 1 gigás méretéhez, 16 millió kódsorához képest, csepp a tengerben, akár benne is hagyhatnák. Értem, hogy ezek elég régi, legacy platformok, talán már nem is futtatják elfogadható teljesítménnyel a modern kerneleket, disztrókat, de én a helyükben benne hagynám, amíg nem jön elő javíthatatlan bug, amit fenntartó hiányában nem tudnak tovább patkolni.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

de én a helyükben benne hagynám, amíg nem jön elő javíthatatlan bug, amit fenntartó hiányában nem tudnak tovább patkolni.

Valahol olvastam, hogy az Alpha EV5 port már egy ideje broken, a port egyes részei tele vannak kóddal amik nem tudnak működni jelen formájukban azon a gépen, és minden jelenlegi disztró ami még támogat Alpha-t (pl. a Debiannak van portja rá), az ennél újabbat kér. Szóval vagy kivágják, vagy masszív bugfixeket igényelne... Amit senki nem akar beletenni.

A PPC portot meg jelentős részben az IBM és vidéke tartja karban és a corporate controlled open source keretében szeretnek belőle mindent kihajigálni, ami nekik már nem kell és "útban van". Gondolom a 40x-ekre is lejárt valami support szerződés, és mivel ezek a low-end PPC-k sok speciális kódot igényelnek, senki nem ugrál a karbatartásukért... Meg amúgy is, valszeg nem számítana az sem, ha valaki fellépne karbantartóként. A Go is így járt, abból az egész 32bites PPC-t meg a 64bit régebbi verzóinak supportját is kivágták pár éve, hiába jelentkeztek volna külsős karbantartók rá...

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Ja, ez így más. Ha tényleg el van törve az Alpha kód benne, és a PPC-t meg maga a kódfenntartó, az IBM nyírja ki, akkor azzal a Linux kernelesek valóban nem tudnak sok mindent kezdeni, csak kiszedni, bár én még ilyenkor sem feature-ként reklámoznám.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( Carter | 2024. 05. 07., k – 15:17 )

mindig akad valami minimal oprendszer, most is van? Mint 20 éve volt a linux, amíg nem lett 16 millió soros a kernel :)

A Fuchsia nem ellensége a Linuxnak vagy Androidnak. Nyílt forráskódú rendszer az is. Működőképes és számtalan előnyös képessége van a korábbi mikrokerneles rendszerekre jellemző teljesítményvesztés nélkül. Felépítéséből adódóan biztonságosabb és jobban skálázható rendszer. A Google-nél folyamatos a fejlesztése de nem tűnik úgy, hogy közeljövőben kezdenének vele valamit. Ezalatt Kínában az amerikai eredetű boszorkányüldözés miatt pályát módosított Huawei fejlesztett valami nagyon hasonlót mint a Fuchsia. Ez a Harmony Next. Sajnos a teljes rendszer nem nyílt forráskódú, csak a rendszer magja. A Fuchsiaval ellentétben ez már nem csak egy labor OS hanem hamarosan eszközök millióin működő rendszer. Okosórától mobiltelefonokon át szuperszámítógépekig jól skálázható. Akár okosóránál is gyengébb hardverű beágyazott eszközökön is elfut. A Linux kerneles android-variáns wearos ma is kínlódik okosórákon, itt már előnyben van a Harmony next. Egy másik előnye, hogy a jövőben lehetőséget teremt az Android és iPhone mobilokban is megtalálható második önálló SoC rendszer elhagyható legyen, amin networking és telephonyt biztosító önálló rendszer fut. Újra visszaköltözhet a fő rendszer processzorára ez a funkció, ami azóta már sok magos SoC chippé fejlődött minden mobilban. Valaha egyetlen arm magon megfért egymás mellett a mobil hálózat kezelése és a többi okostelefonos funkció. A Symbian ezt 70%-30% nem túl hatékony fix időosztással oldotta meg, de legalább stabilan. Openmokon állítólag Linux kerneldriver oldotta meg a mobil hálózat kezelését, erről csak olvastam nekem nem volt Openmokos mobilom. 
Ennek a jelentősége abban áll, hogy pont az 5G technológiákat elsők között támogató Huaweihez kötődő HiSilicon Kirin chipek miatt kezdődött az amerikai boszorkányüldözés. Ha a ma szilíciumba öntött hálózatos kommunikáció teljesen szoftverré változik, akkor könnyebbé válik az arm gyártók közötti választás, persze ha Harmony Next a mobil rendszere. Nemzetközi jogi bohóckodással is nehezebb fogást találni rajta. 

“Az ellenség keze betette a lábát”

Á, közben néztem, nem is annyi már, 1 helyett 1,4 gigára rúg, és 25 674 430 kódsor már közben a Linux kernel (a legutóbbi 6.9-RC7), bár nyilván ebből nem fordul az egész, mert csak 1 architektúrára fordítod, meg nem minden drivert, API-t forgatsz bele, csak ami neked kell, de azért nem egy csöppség. A BSD-k kernele kisebb, bár nincs pontos adat, mert ott a komplett core utils meg minden bele van mérve, de a FreeBSD (~9 millió kódsor), OpenBSD kódbázisa (~3 millió) se kicsi, igaz ez nem mind kernel, így soványabb még, de folyton híznak azok is.

Ha most izgalmas, minimál, POSIX kompatibilis OS kell, akkor Plan9/Inferno, Haiku, Redox OS, amin van is fejlesztés érdemben, többen dolgoznak rajta, igaz a hardver, szoftvertámogatásuk még elég ergya.

Linuxnál nem csak a kernel aggasztó, már önmagában a systemd-ben is van 1,6 millió kódsor, gcc/llvm-ben még több, Rust 1,6 millió LOC, böngészők is ilyen kellemes 16 millió kódsor környékén vannak, amikor ez a sok bloat összeadódik, azért az nem olyan jelentéktelen kódméret egy komplett OS-nél. És akkor még ilyen LibreOffice, meg mást nem is számoltunk hozzá, meg Gtk4, Qt6 hegyeket, nagyobb DE-ket, Electron, Flatpak köztes rétegeket, amik még futnak. Brutál tud lenni.

Androiddal az a baj, hogy nem csak hogy szar, de a Google rajta tartja a kezét, a Fuchsia meg olyan, hogy van, de sose készül el. GNU Hurd esetleg, de hát az is kb. annyira használható, mint egy nyél nélküli wc-kefe, kb. semmin nem fut el normálisan.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

A Linux kernelt is eléggé le lehet slankítani, ha kidobálod belőle, ami nem kell. Pár éve csináltam egy saját Buildroot alapú rendszert, Amigára. A kernelt magát 5-6 mega köré ki lehet hozni, emlékeim szerint, ha elég erősem próbálod, meg nem kellenek ilyen úri murik bele, hogy USB... :D (5.valahanyas kernel, 5.10 talán?) 50Mhz-s 68060-n egész jól ketyegett, 128MB RAM-mal, volt hálózat, minden. A legnagyobb gáz az a disk I/O sebessége volt - max. 2MB/sec, PIO0 az alaplapi IDE port egy Amiga 1200-esen, szóval pár nagyobb szoftver használata türelemjáték volt. Még akkor is, ha egy SD kártyáról futott az egész - tehát nem arra vártunk hogy egy pörgő rozsdalemez felett kóvályogjon az olvasófej. De az akkori komplett céges embedded IoT stackünk végülis tök jól ment rajta. MQTT kommunikáció, Python 3.x, adatbázis, minden...

(Van róla unlisted YT videó is, de nem akarom linkelni, mert van benne pár céges logó, meg evetélt termékekre referencia, amit nem kéne mutogatni, azt mondták... Kár érte.)

Már régóta rajta van a listán hogy áttolom az egészet egy 33Mhz-re overclockolt 68040-es Mac Performa 475-re, aztán akkor az működhet mind dedikált 68k-s Linux tesztgépem. Főleg hogy azon van alaplapi SCSI verzérlő is, szóval TALÁN annyira nem fog fájni, még ha a proci jóval lassabb is lesz...

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Most kezdek majd nemsokara RISC-V-re portolni ezt-azt, kivancsi vagyok mekkora lesz. Bar nagy kovetlemenyek elsore nem lesznek (valami SD kartyas hattertar, HyperRAM alapu memoria), es egy soros konzol. Az a lenyeg hogy ezutobbin keresztul majd az `mc`-t el lehessen inditani, mert akkor mar munkaeszkoz is lesz... 

A yocto egy bloatware ahhoz képest, amivel én szoktam dolgozni :)

1.37 MB, 6.2.5, ARM-ra fordítva.

Nyilván optimize for size, xz tömörítés, és semmi sallang, még modulok se. Egy busybox-ot futtat csak kb. Ez persze nem a "production" kernel, ez csak egy recovery módhoz kell. Ha kell, akár soros vonalon is le bírom küldeni, ez a lényege.

Igen, de ha sovány kernelt akarsz, az kicsit művészet, fekete mágia. Nagyon kell érteni, hogy milyen feature-ök kellenek neked, mik nem, mint szedhetsz ki, hogy még működjön. Gentoo-n ezzel én nagyokat szívtam, vagy 100× kellett leforgatni a kernelt, mert mindig kimaradt valami a támogatásból, EFI stub boot, ThinkPad buttons, ACPI, stb.. Ész nélkül sem lehet szedegetni, mert akkor tényleg be sem bootol, nem működik. Szerteágazó terület, kell hozzá tapasztalat, kezdőnek nagyon frusztráló, ha nem tudja mit csinál.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Az óidőkben -- igaz, hogy NetBSD-hez -- volt egy olyan csomag, 'adjustkernel' néven, ami a 'dmesg' kimenete alapján ,,kigyomlálta'' a NetBSD kernel egyetlen konfigurációs állományából azokat az eszközöket (bejegyzéseket), amelyek ugyan benne voltak az alap 'GENERIC' kernelben, de a dmesg nem találta őket meg...

"Share what you know. Learn what you don't."

Nem tudok róla, hogy Linuxnál lenne ilyen tool, bár nem tartom kizártnak. Nekem még nem jött szembe. Csalni azért lehet Linuxon is, egy fullos generic disztrót bebootolva megnézni, hogy milyen firmware-csomagok vannak fent, meg lsmod-dal listázni a használt kernelmodulokat, az valóban segíthet egy picit, meg a Gentoo Wiki is említ sok mindent, hogy milyen funkciókhoz mit kell engedélyezni a kernel config-ban.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)