Még mindig érkeznek javítások a Linux kernelbe az ősrégi Macintosh II-höz

Kernel
Nem különösebben izgalmas, de látni, hogy 2025-ben a Linux 6.16-ban javítják a valódi Macintosh II hardver felismerését, lenyűgöző volt.

Részletek itt.

( bennyh | 2025. 05. 28., sze – 13:33 )

Nem jó a "Részletek" link, visszamutat arra az oldalra, ahol nézzük.

( Raynes v | 2025. 05. 28., sze – 17:56 )

Elég meglepő. Nem is az, hogy támogatnak régi hardvert, de pl. az ettől erősebb i486 meg néhány korai (nem Pentium) i586 támogatását ki akarják szedni a kernelből, pedig az x86 egy sokkal elterjedtebb, szabványosabb platform. Ez így kicsit felemás.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A 386-os kód nem lassíthat, azt 2012-ben dobták. Az i486-os kód lehet lassít, de azt meg meg lehetne oldani egy a kód elé betett if-fel, ha Pentium előtti CPU-t érzékel, vagy ASM-mel, vagy CPUID-vel, akkor ne fusson le a lassító i486-os kód. Ezért kár támogatást megvonni.

Félre ne értsd, egy 486, K5-ön tényleg használhatatlan egy modern Linux kernel, túl lassú, nyög a memóriahiányban, stb.. De egy i586-os szintű K6-on viszont elmehet, ahogy P2-P3-on is eldöcög. Nekem azzal sincs bajom, ha emellett a Mac II-őt, m68k-t is támogatják.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nem. Ez a 486-os kód csak alig pár ezer sor. Ez elé be lehet tenni egy if-et. Akkor csak nem fut le, mikor nem kell, nem lassít senkinek semmit. Nem általános jelleggel gondoltam, de ha csak ilyen kisebb kódrészletről van szó, annál még működik ez a primitív módszer.

Egyébként rosszul írtam, ha Pentium előtti CPU-t érzékel, akkor betöltődik, egyébként nem. Sikerült fordítva írni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nem, ez nem igaz. A sok tizenmillió kódsor az az összes driver, meg össze architektúra, az nem fordul mind bele a kernelbe egyszerre, és a nagy részét a 486 kód egyébként sem érinti.

Ahogy olvastam a 486-os, FPU emulációs kódrész alig pár ezer soros, és csak néhány alrendszert érint, mint pl. a 32 bites x86-os ütemezőt. Azért mondtam, hogy mikor ilyen kisebb kódrész érintett, akkor elég az if is. Még igazából detektálás se kell hozzá, alapból ki lenne kapcsolva, és aki muzeális procin akarja futtatni, az bekapcsolná egy extra kernelparaméterrel. Nem olyan bonyolult ám ez, mint pár fejlesztő próbálja beadni. Vagy pl. kiszedik a defconfig-ból, meg generic konfigból, akkor nem fordul bele a kernelbe, aki meg régi gépre hegeszti a rendszert, az belefordítja. Annyi kulturált megoldás van a kiszedésen kívül, hogy nem igaz.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Egy friss linux distrohoz már amugy is lassú, hogy bármit csinálj vele, régieket meg eléred továbbra is. Szóval érdekel, hogy szerinted egy friss kernel támogatásához mit ad hozzá egy ezeréves cpu gen támogatása? Szerintem semmit, ahol netán valami régi gép miatt fut még ilyen azt már 10 éve se frissítette senki mert a rajta lévő célszoftver sem indulna el újabbon. Aki retrozik az ugyis régi os el teszi.

Ez így van. De azért nem kéne ellehetetleníteni a régi hardvereket sem, ha kell rájuk valami újabb szoftver. Mostanában nagyon gyomlálják ki az ilyeneket, a i386-os mindenki dobta, az i486-ot is most már csak a NetBSD fogja támogatni. FreeBSD már 64 bit only, Dragonfly BSD 64 bit only de még az AVX-et is megkövetelik, az OpenBSD támogatja az i586-ot, de a Pentium a belépő hozzá. Félő, ha a NetBSD is dobja, akkor ezek a gépek modern rendszer nélkül maradnak teljesen.

Ráadásul ez az i486 és nem Pentium i586 azért is kényes, mert elég sok ipari vezérlő tartalmaz ilyen procit, 486-ost, Vortexet, stb., meg ezzel kizárnak néhány Pentium sebességű, de nem Pentium utasításkészletű procit (AMD/Cyrix 5x86, Cyrix 686, IBM 6x86MR).

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Pont az a baj, hogy a kód tele van ilyen #ifdef-ekkel. A Pentiumban bejött egy csomó fontos feature (pl CMPXCHG, mint szinkronizációs művelet, rendszerhívásra SYSCALL az INT helyett), amik helyett macerás emuláló workaround-ok kellettek 486-ra. Nem is annyira az a baj, hogy futási időben lassítana (nem fordul be, ha a kernelt nem arra target-re fordítod), hanem hogy emberileg nagyon nehezen karbantartható a kód tőle. Ráadásul már nincs is rutinszerűen tesztelve a legacy code path, simán lehet, hogy egy változtatás valahol máshol észrevétlenül eltöri a i486 támogatást és hosszú ideig nem is derül ki. Ezért akarják kukázni.

Az m68k kb a 68060 körül megállt az időben, ami kb a Pentium kortársa volt. Ott nincs ennyiféle későbbi változás, amit le kéne fedni a kódnak.

Régóta vágyok én, az androidok mezonkincsére már!

Ez logikus. Ez ellen nem nagyon tudok érvelni. Ennek ellen továbbra is visszásnak érzem, hogy egy sokkal hasznosabb i486-i586 nem lesz támogatva, de egy nálánál gyengébb, muzeálisabb m68k platform meg igen. Kicsit olyan önkénynek tűnik így kívülálló szemével.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nem az a lényeg hogy mennyire múzeális. Ne csak az asztali gépekre gondolj. Az m68k nagyon sok beágyazott rendszerben ketyeghet még! Itt van mellettem egy ipari vezérlő MCU kártyája m68k processzor maggal és nem olyan meglepő módon linux kernel hajcsa! :-)

( influencer | 2025. 05. 29., cs – 10:00 )

Az egész kernel architektúrát kellene átgondolni, hogy meg tudjon maradni az összes régi támogatott hardver, de csak azokat töltse be és azok legyenek a kernelben, ami releváns. Tehát "if" szinten se legyen a kernelben az, ami biztosan nem fog kelleni az adott hardverben.

Ha egyszerű lenne ezt megoldani, már rég így lenne, nyilvánvaló.