Linux driverek sorsa vált kérdésessé az Intel átalakulása miatt

HUP cikkturkáló

Linux driverek sorsa vált kérdésessé az Intel átalakulása miatt

Mérnöki támogatás nélkül maradtak egyes Linux kernel illesztőprogramokért felelős projektek a chipóriás szerkezetátalakítási intézkedéseinek nyomán, így a későbbiekben felmerülhetnek kompatibilitási és megbízhatósági problémák.
 

  • 924 megtekintés

( ricsip v | 2025. 08. 18., h – 17:09 )

Szerkesztve: 2025. 08. 18., h – 17:17

Szar látni, hogy ezt a céget is pillanatok alatt így szét tudta barmolni a felsővezetés. Mármint nem az történt pillanatok alatt h. ilyen mély gödörbe kerültek, azt hosszú évek alatt sikerült elérni, és már évek óta ment a susmus. Hanem h. azt a 30-35 ezer nyomorultat így kirakják egyik napról a másikra. Tudtommal egyszerre rúgták ki azt a 30%-ot már hetekkel ezelőtt, nem az van h. több etap-ban megy pl. kéthetente az újabb halállista az új nevekkel. Ez a kemény, 35 ezer embert kinyírni egyik napról a másikra. Elképzelem h. az intel HQ-ban bent ment a céges menzán a sutyorgás a hr-es emberek között: kitalálnak ezek a szopciopaták mindenféle kódneveket mint az amerikai hadseregnél. Hogy ha valaki esetleg véletlenül fűltanúja lenne valami nagyfejűek pofázásának a Project Zebra-ról, akkor se tudja h. a Project Zebra konkrétan azt jelenti h. 35 ezer embert kirúgunk július első hetében.

A tudás meg egy pillanat alatt szétszéled, gondolom tárt karokkal várnak a TSMC-hez minden kirúgott foundry-s mérnököt. Az ARC linux drájverírók mondjuk gondolom a kutyának se fognak kelleni.

Az Arc projektet pont nem építették le, az az egy nem érintett. Szerintem az Intel belátta, hogy a GPU-ba túl sokat invesztált már, sose térülne meg, ha most jegelnék. Az nagy baromarcúság is lenne, mivel az NVidia lényegében már csak AI/szerver területen érdekelt, home/gaming szegmensben már nem, és az utóbbiba kell egy másik gyártó az AMD ellenében, hogy legyen verseny.

Egyébként sajnálom az Intelt, hogy így padlót fogtak. Amit nem is értek, mert annyira rosszul nem álltak még, se a GPU-ik, se a prociaik nem voltak rosszak, jó, kicsit fogyasztásban hátrébb vannak, meg volt ez a durva 14. genes procik megsütik magukat fiaskó, de az sem volt olyan méretű, hogy beleálljon miatta az Intel a földbe, tragikusan visszafordíthatatlan legyen. Mióta feladták a saját gyártást, és csak a CPU/GPU tervezést tartották meg, azóta mintha jöttek volna fel, nem voltak még úgy lemaradva, hogy ilyen drasztikus intézkedésekre legyen szükség.

Ha érintve is lenne, akkor pont az Arc fejlesztők lennének, akik kellenének valahova. Pont az egyik legértékesebb tudás a GPU driverírás, meg ezek eleve ex-Nvidia-szakemberek, ezeknek a tudása bárhova kell, ritkaság, érték.

“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.”

De a FAB-okat nem építették fel, ARC-ból máris kijött több generáció, abba régebb óta temetik a pénzt. Azt vártam egyébként, hogy elkaszálják azt is, de jó látni, hogy az Intel vezérnek talán nem teljesen ment el az esze. Azt eltemetni most óriási hiba lenne, lényegében az AMD kerülve vele monopol helyzetbe a home/gaming GPU piacon. Érzésem szerint az ARC vonalat azért nem kaszálta, mert annak hasznát veszik integrált GPU-knál is, valami kell a CPU-jaikba, hogy tartsák a versenyt az AMD-vel.

“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.”

( jevgenyij | 2025. 08. 18., h – 18:47 )

Linus dogmája szerint ugye Stable API nonsense! 

Így ez valóban hamar problémát fog okozni. 

Ha lenne stable API Linuxszon akkor legalább a már elkészült driverekkel és hozzájuk kapcsolódó Intel cuccokkal nem lenne probléma egy jó darabig. 

A másik dolog ami megoldást jelentene erre illetve hasonló szituációkra, az a bizonyos mikrokerneles felépítés. Linus másik dogmája szerint ez is egy ilyen felesleges akadémikus dolog. Pedig egy modern mikrokerneles rendszeren sokkal kisebb kockázatot jelentenének az elárvult (de működő) driverek. 

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

ha egy driver nincs karbantartva az ellen semmilyen api nem ved.

Ha nincs karbantartva, de egyébként jól muzsikál, akkor ugyan miért okozhatna gondot? Ami működik, azt nem kell megjavítani.
A minix-ben például egyszer megírták az IDE meghajtót, soha többé nem nyúltak hozzá, és jé, mind a mai napig remekül működik. Igaz, minix-ben az API stabil, mert fix formátumú üzenetekből áll.

Igaza van jevgenyijnek, a mikrokernel nagy előnye (a szeparáláson túl) az is, hogy az üzenetek formátuma nem változik, stabil.

Azt amúgy miért nem lehetne, hogy a jelenlegi belső API állapotot befagyasztják, és csak akkor piszkálnak hozzá, ha olyan biztonsági vagy teljesítmény beli probléma merül fel, amit csak nagy taknyolással vagy még úgy sem lehet megoldani? Vagy pont ez a helyzet, csak túl sokszor kell módosítani valamit?

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

csak tippelek, de ez az új, jövőben kiadandó hardvereket érinti főleg, hogy azok támogatását nem lesz, aki megcsinálja.

Az eredeti levelet nem olvastam, mert nem linkelték be a hírben. De lehet félrefordították a jelentését.

Amennyire rálátok, nagyjából ez a helyzet. Nagyobb struktúrák és a hozzájuk tartozó helperek gondolok itt a socketekre, netdevre, taskra, namespacere, stb. nagyon ritkán módosulnak, vagy ha igen ott elég triviálisan lehet rebasel-ni. Egyik nagyobb, globális változás nemrégről a tasklet leselejtezése a workqueue javára: gyakorlatilag sed s//g szinten cserélhető a dolog, és 5-10 évente egyszer van ekkora változás. Folyamatban a struct page -> folio migrálás ahol csak lehetséges, itt szintén egyértelmű mit mire kell cserélni. Sajnos még triviális cserék is össeadva kiadnak egy olyan fenntartási költséget, amik ellehetetlenítik, hogy egy 5-10 éve írt kernel modul legrisebb kernellel működjön.

Viszont ami egyszer upstream lett, ott sok esetben nagyobb API válrozásokat megoldja más, aki az új API-t javasolja. Az igazi gond nem az instabil API szerintem, hanem a driverekben megbújó bugok és olyan funkciók, amik nincsenek implementálva. Pl. vegyük a WWAN drivert, amihez néhány éve lett generic API, amit már nem csak Intel használ. Ha ennek a drivernek nincs maintainere, akkor hiába jelenik meg például hardveres időbélyegzés funkció és kapcsolódó beállítások az API-ban, nem biztos hogy lesz aki ezt implemetálja az Inteles WWAN driverben. Ettől függetlenül a kártya még működni fog, ahogy eddig, mert olyan változás nem jöhet, ami azt eltöri.