Linus Benedict Torvalds je finsko-ameriški programski inženir, znan po začetku in vzdrževanju razvoja jedra Linuxa,
Pred kratkim med razpravo o rešitvah na procesorjih x86, ki ne podpirajo Navodilo «cmpxchg8b», je Linus Torvalds izjavil, da je morda čas, da naredite to izjavo obvezno za delovanje jedra in odstranite podporo za procesorje i486 ki ne podpirajo "cmpxchg8b", namesto da "poskušajo posnemati, kako" ta navodila delujejo na procesorjih, ki jih "nihče več ne uporablja".
Trenutno so skoraj vse distribucije Linuxa, ki še naprej podpirajo 86-bitne sisteme x32, prešle na prevajanje jedra z možnostjo X86_PAE, ki zahteva podporo za "cmpxchg8b".
Po besedah Linusa, kar zadeva podporo v jedru, so procesorji i486 izgubili pomen, čeprav jih še najdemo v vsakdanjem življenju. Procesorji na določeni točki postanejo muzejski eksponati in zanje je povsem mogoče preživeti z »muzejskimi« jedri.
Omeniti velja, da če bo odprava podpore za klasični i486 potekala, to ne bo vplivalo na Intelove vgrajene procesorje Quark, ki, čeprav spadajo v razred i486, vključujejo dodatna navodila, značilna za generacijo Pentium, vključno z "cmpxchg8b ».
Poleg tega je omenjeno, da enako velja za procesorje Vortex86DX. Podpora za procesorje i386 je bila opuščena v jedru pred 10 leti.
Mogoče bi morali ugrizniti in reči, da podpiramo samo x86-32 s 'cmpxchg8b' (tj. Pentium in novejši).
Znebite se vsega "emuliranja 64-bitne atomike s cli/sti, saj veste, da tako ali tako nihče nima SMP na teh procesorjih", in implementirajte generično nastavitev x86-32 xchg() z uporabo te zanke try_cmpxchg64.
Mislim, da večina (vseh?) distribucij že tako ali tako omogoča X86_PAE, zaradi česar je X86_CMPXCHG64 del osnovne zahteve.
Ne, da sem prepričan, da večina distribucij danes sploh izvaja 32-bitni razvoj.
...
Leta 386 smo se znebili podpore za i2012. Mogoče je čas, da leta 486 opustimo podporo za i2022?
Konec podpore za i486 bi lahko bil mejnik, o katerem bi morali razmisliti, saj so se nedolgo nazaj različne distribucije Linuxa odločile odpraviti podporo za 32-bitne procesorje, kar pa ni imelo posledic, kot so mnogi pričakovali. Ker da, še vedno obstaja na tisoče uporabnikov, ki imajo računalnike z nizkimi viri, zaradi česar je Linux odlična možnost za njihovo nadaljnjo uporabo, zlasti na številnih marginaliziranih območjih.
In čeprav so glavne distribucije še naprej podpirale to vrsto opreme, so njihove trenutne zahteve onemogočale njihovo uporabo. Resnica je, da še vedno obstajajo nekatere distribucije, ki še naprej podpirajo to arhitekturo in so predvsem optimizirane za uporabo računalnikov z nizkimi viri.
V zvezi s primerom prenehanja podpore je omenjeno, da je uporabniki, ki imajo sisteme s procesorji i486, bodo lahko uporabljali LTS različice jedraki bo trajal še mnogo let.
Po drugi strani pa velja omeniti tudi to razvijalec gonilnikov za Linux open source za Apple AGX GPU ki se uporablja v čipih Apple M1, je poročal, da uspešno opravil 99,3 % testov paketa dEQP-GLES2, ki preverja raven podpore za specifikacijo OpenGL ES 2. Pri delu sta bili uporabljeni dve komponenti: gonilnik DRM za jedro Linuxa, napisan v Rustu, in gonilnik Mesa, napisan v C.
Razvoj krmilnikov je zapleteno zaradi dejstva, da Apple M1 uporablja lastno GPE, ki ga je zasnoval Apple, poganja lastniško vdelano programsko opremo in uporablja dokaj zapletene skupne podatkovne strukture. Za GPE ni tehnične dokumentacije, neodvisen razvoj gonilnikov pa uporablja obratni inženiring gonilnikov macOS.
Krmilnik open source razvit za Mesa je bil prvotno preizkušen v okolju macOS dokler ni bil pripravljen gonilnik DRM (Direct Rendering Manager), potreben za jedro Linuxa, kar je omogočilo uporabo gonilnika, razvitega za Mesa, v Linuxu.
Poleg trenutnega uspeha pri opravljenih testih dEQP-GLES2 je gonilnik Linuxa za čipe Apple M1 konec septembra dosegel raven, ki je primerna za izvajanje seje GNOME, ki temelji na Waylandu, ter za izvajanje igre Neverball in YouTube v brskalniku Firefox.
Končno če vas zanima več o tem, podrobnosti lahko preverite v naslednja povezava.