Dobja a Linux kernel a i486 támogatást (ha már meg nem tette)

Kernel
[...] Több mint 36 évvel a 486 megjelenése és 18 évvel azután, hogy az Intel leállította a gyártását, a Linux kernel vezetői úgy gondolják, hogy a projekt előrébb léphet azzal, ha maga mögött hagyja az i486 támogatását. Ingo Molnar, Linus Torvalds szavait idézve – miszerint „semmilyen valós oka nincs annak, hogy bárki akár egy másodpercet is elpazaroljon” a 486 támogatására –, patch sorozatot nyújtott be a 6.15-ös kernelhez, amely frissíti a minimális támogatási követelményeket. Ezek mostantól magukban foglalják a TSC-t (Time Stamp Counter) és a CX8-at (azaz a „javított” CMPXCH8B-t, ami önálló egységként értelmezendő) – olyan funkciókat, amelyek hiányoznak a 486-ból (és néhány korai, nem Pentium-alapú 586 processzorból is).

Ez nem az első alkalom, hogy Torvalds javasolja a 32 bites processzorok támogatásának megszüntetését, és ezzel a kernel fejlesztőinek tehermentesítését az elavult emulációk és kerülő megoldások implementálása alól. „2012-ben megszabadultunk az i386 támogatásától. Talán itt az ideje, hogy 2022-ben az i486-tól is búcsút vegyünk” – írta Torvalds 2022 októberében. Hacsak nem történnek jelentős változások a 6.15-ös kernelben, amely várhatóan a hónap végén érkezik*, az i486 támogatása el fog tűnni. [...]

Részletek itt, itt és itt.

(* Azóta megjelent.)

( Raynes v | 2025. 06. 01., v – 12:40 )

Ahogy itt már írtam, én nagyon nem támogatom. Elég sok olyan ipari vezérlő van, amin emiatt nem fog futni, amelyek nem 486-osok, de nem is Pentium szintűek (pl. K6, Vortex), de amúgy elfutna rajtuk egy modern minimál Linux.

Illetve kicsit elaprózottnak is látom, mert az i386-ot kilőtték már 2012-ben, most az i486 és a nem-Pentium i586 a soros, de akkor már felesleges itt megállni, meg elaprózni a többit, a következő pár évre csepegtetve, mert csak a i586 Pentium meg az i686-os procik maradnak, akkor már az egész 32 bit only támogatást ki lehetne dobni, az valóban sokat egyszerűsítene a kódon. Néhány P2-P4-es, meg néhány K7-es és régi Atom procis gépet érintene csak extrában, amit szintén nem akarnék, de ha már lúd, akkor legyen kövér, csinálják úgy, mint a FreeBSD, akik nem aprózták el, meghúzták a határt, hogy a 15-ös kiadástól kezdve az egész nem multiarch x86_32 szanálva lesz, nincs kivételezgetés, meg egyes utasításokon rugózás. Az valóban sokat segít, userek is könnyebben kiderítik, hogy mi támogatott, meg ha 64 bit only a kód, akkor nem kell PAE-vel, meg MMX vizsgálattal szórakozni, hanem mehet a SSE, CMOV, CMPXCHGakármennyi, stb.-re építés, sok mindent nagyban egyszerűsít, optimalizál. Nagyban megoldja a 32 bites unix timestamp problematikáját is, így ki lehetne dobni egy füstre egy csomó 32 bites hekket.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Szerintem meg van LTS kernel, szóval ezekhez a vezérlőkhöz is lesz kernel még pár évig. Plusz azt se tudom, hogy mennyi ilyen vezérlő működhet még a valóságban, de ha nem kötik őket a netre, akkor egy LTS-sel boldogan élnek, amíg meg nem halnak.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

>  felesleges itt megállni

teljesen egyetertek. ha mar a reisert kidobtak, dobjanak ki minden 10 evnel regebbi vackot. azt meg kell tartani a 6.x lts-nek es jojjon a 7-e svagy 10-es verzioju kernel amiben csak korszeru megoldasok, arch-ok, fs-ek, driverek vannak. ja es ha mar ugyis ott vannak irjak at rustra az egeszet mert most epp az a divat :)

Nem tudom, hogy most csak szarkazmusból írod, vagy egyetértesz. Félre ne értsetek, én azt szeretném, hogy igazából semmit ne dobjanak, tényleg csak akkor, ha a kód bizonyíthatóan el van törve az aktuális hardveren és nincs aki javítsa, akkor igen, vegyék ki, addig viszont hagyják benne, amíg csak lehet.

A reiserrel nem azt volt a gond, hogy kivették, hanem hogy nem hagytak hozzá userspace eszközöket, hogy ki lehessen menteni a cuccokat róla, így csak az marad, hogy fel kell tenni egy régi kernelt a mentés idejére. Csúnya húzás.

Mert ennek a köztes játéknak, amit most játszanak nem sok értelme van, metszegetik kicsit itt-ott a kódot. Gondolom azért aprózzák, hogy ne legyen belőle közfelháborodás. Nem, nem kell a 10 évnél régebbieket szanálni ilyen mechanikusan, a 64 bitnél elég csak a 2005-ös x86_64-es procikig visszamenni (az első 2003-2004-es AMD64-ekből hiányzott pár fontosabb utasítás), az is 20 évre visszamenőleges támogatás.

Abban egyetértek, hogy a Rust-ot nem lett volna szabad a kernelbe engedni. Akkor sem tűnt jó ötletnek, az idő szerintem be is bizonyította, hogy nem jó ötlet. Ha a Rust-osok annyira szeretnek átírni, írják át maguknak elölről az egész Linux kernelt, és taknyolják akkor azt Rust-ban, ne az eredeti C-s projektet és fejlesztőket frusztrálják ezzel.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A Win11-nél sem az a baj, hogy nem támogat 20 évre visszamenőleg mindent, hanem hogy egy nagy fos az egész. Nem indokolja semmi a nagyobb hardverigényt, csak önkényesen avultattak el vele. Mert ha azt valami fontos extrát nyújtana az új hardvereken, akkor megértem, hogy a fejlődés érdekében szükséges volt, de így nem az.

Azt pl. helyeslem is, hogy a 32 bitet végre dobta a MS, annak már nagyon ideje volt. De ilyen 5-7 éves, nagyon is használható Core i, meg első genes Zen procikat dobni nagyon durva volt a semmiért, még a VBS-ért sem volt értelme, mert azt tudta a Win10 is, régi procin is, legfeljebb kicsit nagyobb overheaddel.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Szerintem a 64 bites kódban eddig sem kellett ezeket vizsgálni, ugyanakkor az extra utasításkészletek nem összekeverendőek az amd64-el. Én legalábbis nem tudok róla, hogy az amd64 megkövetelné, hogy MMX legyen a processzorban, bár nem tudom hogy létezik-e olyan, amiben nincs.

A Microsoft a Windows AMD64 portjában a komplett x87 FPU-t legacynak minősítette és SSE2-t ír elő lebegőpontos számításokhoz, valamint az ABI-ban is ez szerepel függvényhívásokhoz. Mivel az MMX az FPU regisztereket használja, ezért a Microsoft szempontjából az is elavult. (A gyakorlatban az x87 FPU és az MMX továbbra is működik Windows alatt is, AMD64 kódban is, de használata erősen ellenjavalt.)

Más kérdés, hogy az AMD által is definiált és a Linux által is használt SysV ABI továbbra is tartalmazza mindkettőt, szóval a gyakorlatban a rendszer nem, vagy csak részlegesen működne egy ezt nélkülöző AMD64 processzoron. A gyakorlatban nem is létezik ilyen chip, legalábbis "halandók" számára "bemegyek a boltba, megveszem, installálok rá OS-t" szinten biztosan nem.

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

Az AMD64 nem követeli meg az MMX-et, de minden x86_64-es proci támogat SSE2-t helyette, ami még jobb az MMX-nél, arra tudsz optimalizálni. Ha natív 32 bites módot támogatsz, akkor viszont nem tudod feltételezni, hogy akár MMX, vagy akár SSE, akár SSE2 lesz benne. Így csak az AMD64-nél ez kényelmes egybeesés hogy 64 bites prociból nem jött ki olyan, ami ne támogatná az SSE2-őt, de nem követelmény.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Az érdekesség, hogy az x86-S, amit kb 1 éve még nyomatott az Intel, aztán csendben elengedte, abban sem volt szó az MMX dobásáról. Pedig ott az x86-32-t nagyon durván visszavágták, kb a ring3 maradt volna, még VM-ben sem tudtál volna 32 bites OS-t futtatni, csak 64 bites kernel felett 32 bites userspace-t.

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

( Chain-Q v | 2025. 06. 02., h – 00:12 )

Biztos nem új ötlet, de ugyanúgy ahogy pl. a 68k support sincs "útban", a nagyoknak, ha csinálnának egy x86-legacy architektúrát v. nevezd aminek akarod, akkor ki lehetne szórni az útban lévő dolgokat a modern CPU-k supportjából, miközben meg lehetne tartani a ezeknek a régi dolgoknak a támogatását. De persze szvsz már az egész 32bit x86 support réges-rég legacy-nak minősül... Szóval akkor meg valóban minek elaprózni, le kell választani teljesen a 32bitet és a 64bit mehet előre, a 32bit x86 meg ellehet a saját kis retró-homokozójában, hátha még van pár ember akit érdekel és karbantartaná.

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

( hunluki | 2025. 06. 02., h – 08:47 )

Kb egyetértek a fentiekkel, ahol ilyen régi vasak vannak szinte biztos hogy el vannak szeparálva külön hálózatra és kényelmesen elprüntyögnek a korukbeli kernellel, valószínűleg az újabbakat be se tudnák bootolni vagy olyan lassú lenne hogy értelme nem sok van.

Amúgy nektek mi a legrégebbi gép amit életben tartotok? Ha linuxos akkor mi fut rajta és hanyas kernellel?

Nálam a pincében van egy öreg pentium, gondolkodtam rajta hogy felélesztem csak a móka kedvéért de még nem sikerült rá időt találnom. Fősuliban egyik osztálytársam tolta egy p2-es laptoppal 64 mega rammal akkori puppy-val, én egy p3-as "netbook"-ot használtam puppy/XP dual boot-al. Ezek már akkor régi vasnak számítottak, akkoriban p4 korszak eleje-közepe környékén jártunk.

Amúgy nektek mi a legrégebbi gép amit életben tartotok? Ha linuxos akkor mi fut rajta és hanyas kernellel?

trey@foobar:~$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 5
model name	: Pentium II (Deschutes)
stepping	: 0
cpu MHz		: 400.916
cache size	: 512 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 2
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr
bogomips	: 802.93

uname -a
Linux foobar 2.6.15-27-server #1 SMP Fri Dec 8 18:43:54 UTC 2006 i686 GNU/Linux

trey @ gépház

Amúgy nektek mi a legrégebbi gép amit életben tartotok?

Egy Asus TUSL2-C alaplap, Pentium III procival és 512 MB memóriával:

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 10
microcode       : 0x1
cpu MHz         : 1002.341
cache size      : 256 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 mmx fxsr sse cpuid pti
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_unknown
bogomips        : 2004.68
clflush size    : 32
cache_alignment : 32
address sizes   : 36 bits physical, 32 bits virtual
power management:

$ uname -a
Linux szerviz 6.1.140 #1 SMP PREEMPT_DYNAMIC Mon May 26 09:00:00 CEST 2025 i686 GNU/Linux

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Van még egy AlphaStation 255/233, de azt kb. egy éve nem kapcsoltam be. 5.4.282-es kernelt fordítottam rá utoljára, és Debian 5.0.10 van rajta (mivel Alpha-ra nincs újabb Debian, újabbat fordítani magamnak pedig nem volt hangulatom).

( bennyh | 2025. 06. 02., h – 09:06 )

Az nem opció, hogy a régi, nem támogatott eszköz elé, ha nagyon kell hálózat, pakolni kell egy kisebb Mikrotik vagy OpenWRT alapú routert, azon belőni azt, amit nagyon kell a napi működéshez? Tudom, valami forgalomelemző tűzfal jobb lenne.

( Botond | 2025. 06. 02., h – 13:00 )

"Ez nem az első alkalom, hogy Torvalds javasolja a 32 bites processzorok támogatásának megszüntetését"

Hát remélem, Linus nem pont ezt mondta. Esetleg az x86-32 procik támogatásáról beszélhetett? Ugyanis a beágyazott világban a procik nagy része még mindig 32-bites, és szeretünk Linux-ot futtatni rajtuk.

Ez év januárjában még jöttek improvement-jellegű patch-ek kifejezetten x86-32-re: https://lore.kernel.org/lkml/20250123172428.D6D8C8D9@davehans-spike.ostc.intel.com/

A necces dolog a PAE-nélküli x86-32 támogatás, arról már volt szó párszor, hogy dobni akarják. A fő baj nemcsak a >4GB memória, hanem hogy nincs NX bit támogatás sem PAE nélkül, emiatt teljesen más memóriavédelmi modellt kell karbantartani a non-pae esetre. Emlékeim szerint már 10 éve is kézzel kellett kernel forgatni Pentium M-es notebookra, mert a legtöbb mainstream disztro már dobta a non-pae kernelt, a Debian talán még tartja, de már rég néztem.

EDIT: amúgy most olvastam utána, miután a 1995-ben a Pentium Pro-t behozták PAE támogatással, 2003-ben kiadták az i686-os Pentium M-eket, mint utolsó "nagy" 32-bit-only generációt, PAE nélkül... Ráadásul beágyazott rendszerekben ez kifejezetten népszerű volt, legalábbis telco környezetben biztosan. Komplett mobilközpontok futottak Pentium M-eken, igaz nem Linux alapú, hanem proprietary OS-sel.

Amúgy írják, hogy van nála hanyas benne PAE, csak CPUID-ben nem hirdeti a feature flag-et. Ez is de szép baleset volt anno...

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