Torvalds brengt release candidate Linux 4.2-rc1-kernel uit

Linus Torvalds heeft versie 4.2-rc1 zondagavond uitgebracht. Daarmee wordt 4.2 niet de kernel met de meeste wijzigingen ooit, maar het komt wel in de buurt van de 3.10-release. Het gros van de nieuwe regels code is toe te schrijven aan de nieuwe amdgpu-grafische driver.

Dat schrijft Torvalds in zijn twee wekelijkse kernel-mailing. Hij zegt dat met meer dan een miljoen regels toegevoegde code en ongeveer een kwart miljoen verwijderde regels, hij wel de release candidate 3.11-rc1 verslaat. Daarbij was de toevoeging van het Lustre-bestandssysteem de belangrijkste reden van het grote aantal toegevoegde regels. Het aantal toegevoegde regels aan de 3.10-kernel was uiteindelijk groter door het aantal wijzigingen die nog doorgevoerd werden tussen de rc en uiteindelijke release.

De nieuwe amdgpu-kerneldriver, waarbij alleen de headers al verantwoordelijk zijn voor 41 procent van de hele patch en nog eens 8 procent voor de driver zelf, moet ervoor zorgen dat de nieuwste en toekomstige Radeon-gpu's ondersteund worden. Verder is er ondersteuning voor Intel Broxton Atom-socs en uitgebreidere ondersteuning voor verschillende ARM-cpu's, F2FS-bestandssysteem met per-file-encryptie en andere hardware. Ook is ext4 opgeschoond en onder handen genomen met verschillende fixes.

Andere opvallende wijzigingen zijn verbeteringen aan het audiosysteem, met onder andere ondersteuning voor Intel Skylake audio. De ALSA hda/hdmi-code heeft nu ondersteuning voor Nvidia's Tegra 3-, Tegra 4- en Tegra X1-socs. Ondersteuning voor verschillende controllers, zoals de Logitech M560 en Sony Motion Controller van de PlayStation en verschillende andere controllers. De nieuwe rc is te downloaden op de bekende plekken.

Reacties (36)

[CAPSLOCK2000]

Ik snap eigenlijk niet waarom de AMD GPU driver onderdeel uit maakt van de kernel. Betekend dit dat je zonder kernel ondersteuning niet een nieuwere videokaart zou kunnen gebruiken? Het is toch ook niet zo dat alle hardware standaard door de kernel ondersteund moet worden om te functioneren? Dat is toch juist het idee van drivers (die zelfs in user-mode kunnen draaien zodat een slechte driver niet het hele systeem plat trekt). Of is dat alleen in Windows zo?

Linux levert de meeste drivers met de kernel mee. In principe kun je ze ook los distribueren maar dat is veel minder gebruikelijk dan onder Windows.
Windows heeft een hele rigide interface tussen de drivers en de rest van de kernel. Dit heeft als voordeel dat het makkelijk is om drivers los te verspreiden maar het nadeel dat het moeilijk is om grote veranderingen door te voeren. Niet dat die interfaces echt heel vaak veranderen. Meestal kun je een driver ook wel compilen voor een oudere kernel versie maar in praktijk doet vrijwel niemand.
Het upgraden van een Linux-kernel is vrij eenvoudig. Het is niet zo'n grote stap om een nieuwere kernel te installeren als je een nieuwere driver nodig hebt. In de meeste gevallen regelt je distributie dat overigens voor je en heb je er als gebruiker geen omkijken naar. Alleen als je de allernieuwste hardware hebt moet je het soms zelf doen. Voor populaire hardware (zoals Intel en AMD in dit bericht) zijn de drivers vaak al beschikbaar voordat de hardware op de markt is.
In dit geval is AMD bezig met een nieuwe driver. Die driver heeft ook ondersteuning voor een paar hedendaagse modellen maar die modellen werken ook met de oude driver. Er is dus geen dringende reden om te upgraden tenzij je een ontwikkelaar bent of graag cutting-edge drivers gebruikt.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 16:13]

[Bliksem B]

Ik dacht dat juist dat Linux kernel sinds enkele versies modulair is opgebouwd, zodat gemakkelijk grote drivers eruit kunnen worden gelaten. Of is dat nog het geval, maar worden deze simpelweg niet in het geheugen geladen?

[CAPSLOCK2000]

De Linux-kernel is al heel lang modulair. Als ik zeg dat de drivers met de kernel mee worden geleverd bedoel ik niet meer dan dat ze samen op je HD worden geinstalleerd. Ze zijn daarmee nog niet geladen. Drivers worden pas geladen als ze nodig zijn. Je kan ze in principe ook weer ontladen en vervangen door een nieuwere versie. Het gebeurd in praktijk niet zo veel omdat de hele handel tegelijkertijd wordt geupgrade. Voor USB-hardware is het echter wel gebruikelijk dat de driver weer wordt ontladen als je de hardware los trekt.

[roy-t]

Ik snap eigenlijk niet waarom de AMD GPU driver onderdeel uit maakt van de kernel. Betekend dit dat je zonder kernel ondersteuning niet een nieuwere videokaart zou kunnen gebruiken? Het is toch ook niet zo dat alle hardware standaard door de kernel ondersteund moet worden om te functioneren? Dat is toch juist het idee van drivers (die zelfs in user-mode kunnen draaien zodat een slechte driver niet het hele systeem plat trekt). Of is dat alleen in Windows zo?

[deadinspace]

Waarschuwing: lange post

Ik snap eigenlijk niet waarom de AMD GPU driver onderdeel uit maakt van de kernel. ...

Een paar weken geleden stelde iemand vrijwel dezelfde vraag in Linux kernel 4.1 beschikbaar, waar ik een heel uitgebreid antwoord op heb gegeven. Omdat dit vrijwel dezelfde discussie is, maar ik geen zin heb weer zo'n lang verhaal te schrijven neem ik even de vrijheid hem hier te copy/pasten

ultimasnake vroeg:

Toch vind ik het nog steeds knap/apart dat in de kernel ondersteuning zit voor dingen waar ik dacht dat altijd drivers voor bedoeld zijn. Waarom zou je in de kernel zelf ondersteuning inbouwen voor een ledje van een specifieke laptop b.v.? Kan iemand mij dit uitleggen? (mogelijk mis ik het hele punt als Mac/windows gebruiker )

Waarop Umbrah antwoordde:

Misschien is het nuttig om kernel ontwerp eens te gaan bestuderen. Linux is een vrij taditionele monlitische kernel. Wel flexibel, maar in feite is alles wat je denkt nodig te hebben onderdeel van de kernel. Er is ook een gigantisch debat voor de modulaire kernel, QNX en Darwin (van MacOS) zijn meer microkernels. Dan heb je natuurlijk ook nog een hybride model (Windows heeft een hybride kernel), wat 'best of both' zou moeten zijn, en in feite is Linux al een beetje die kant opgegaan, uiteraard, maar de kern van dit soort dingen is natuurlijk: "er is een nieuwe kernel, en het filesystem kan ineens meer", terwijl in de Windows kernel de HAL in feite niks kan, en zelfs NTFS een module is.

Leuke discussie:
https://en.wikipedia.org/...m%E2%80%93Torvalds_debate

Hierop antwoordde ik onderstaand verhaal:

Misschien is het nuttig om kernel ontwerp eens te gaan bestuderen. Linux is een vrij taditionele monlitische kernel.

De reden heeft weinig te maken met het (inmiddels achterhaalde) onderscheid tussen monolithische kernels en microkernels.

De Linux kernel core bevat hoofdzakelijk hoognodige infrastructuur; geheugenmanagement, task scheduler, interne libraries voor datastructuren en interne communicatie, etc. (een uitzondering is core TCP/IP, dat zit ook in de kernel zelf).

Al het andere, met name hardware drivers en filesystem drivers, maar ook zaken als extra TCP/IP functionaliteit, het audio subsystem, hashing en encryptie, en software RAID, bestaan als LKMs - Loadable Kernel Modules (onder andere OSsen soms bekend als Kernel Extensions). Dit zijn als het ware plugins, die als ze geladen worden onderdeel worden van de kernel.

Dat laatste is zo ongeveer de definitie van een monolithische kernel; een LKM wordt in de adresruimte van de kernel geladen. Het wordt onderdeel van de kernel, op gelijke voet met de overige kernelcode. Bij een ware microkernel zou een LKM in zijn eigen adresruimte moeten draaien, het liefst als een los user-space proces.

De keyboard-backlight ondersteuning voor Dell laptops bevindt zich dan ook in de Dell laptop driver, "dell-laptop" genaamd. Dit is dus een module, een driver, die geladen kan worden als dat wenselijk is (op Dell laptops bijvoorbeeld ).

Waarom staat dit dan in het nieuwsbericht van Linux 4.1? Waarin verschilt dit van bijvoorbeeld Windows? Dat heeft niet te maken met de architectuur van de Linux kernel, maar het ontwikkelmodel ervan.

Om een kernel driver voor Windows te maken moet je de juiste SDK hebben (in essentie, de juiste header files en compile/link flags). Iemand schijft dan code voor de driver (bv met de SDK voor Windows 7), compiled die op de juiste manier, en vervolgens kan de driver verspreid worden en geladen worden door andere mensen (in de kernel dus, net als op Linux).

De kernel van specifieke Windows-versie heeft een vaststaande interne API/ABI (interface) waardoor dit - als het goed is - werkt. En dat is waar de zaken met Linux gaan verschillen; de Linux kernel heeft geen vastgelegde interne API, laat staan ABI (de ABI die definieert hoe userspace programma's de kernel kunnen aanroepen zijn een ander verhaal, die ligt juist erg vast).

De reden daarvoor is dat Linus de vrijheid wil houden de interne structuur van de kernel te verbeteren. Het resultaat daarvan is dat een LKM gemaakt voor Linux 3.16 mogelijk niet te laden is op 3.17, en misschien zelfs niet eens te compilen is voor 3.17 zonder wijzigingen.

Een ander verschil is dat open source Linux kernel drivers van oudsher in dezelfde source tree zitten als de Linux kernel zelf. Vrijwel alle netwerkkaarten, geluidskaarten, (core support voor) videokaarten, bergen en bergen USB devices, filesystems, al die drivers krijg je mee als je de source voor de Linux kernel downloadt. Dat maakt het vorige puntje, interface-stabiliteit, ook meteen een stuk minder pijnlijk - bij aanpassingen die bepaalde LKMs beïnvloeden kunnen die LKMs ook meteen mee-geupdate worden.

Het betekent ook dat de standaard-plek waar Linux kernel drivers gehost en gereleased worden de Linux kernel source tree is. En dat is waarom je nieuws over Dell keyboardverlichting (waarvan ik me overigens niet voor kan stellen dat het een van de meest interessante verbeteringen is ) terugvindt in een nieuwspost over Linux 4.1.

Als je trouwens de Linux kernel source downloadt en een beetje rondbrowset, dan kun je ook zien hoe de hoeveelheden code zich verhouden. De volledige 4.1 source tree is zo'n 655MB, maar daarvan is de core ergens tussen de 10 en 15 MB: kernel/ (de core) 7MB, mm/ (memory management) 3MB, lib/ 3MB. Groter zijn de interfaces tussen de verschillende onderdelen: include/ 32MB, processorarchitectuur-specifieke ondersteuning: arch/ 131MB en de drivers: drivers/ 333MB, sound/ 29MB, net/ 26MB.

Bovenstaand stukje gaat over de source code, maar het gecompileerde resultaat laat een vergelijkbaar verhaal zien; De (gecomprimeerde) kernel image op mijn systeem, /boot/vmlinuz-3.16.0-4-amd64, is 3MB. Alle beschikbare LKMs (/lib/modules) zijn zo'n 160MB, en mijn systeem telt op dit moment 99 geladen kernel modules (goed voor zo'n 7MB, te zien met lsmod).

Overigens heeft het Linux-model vergeleken met bv Windows zowel voordelen (oude drivers worden goed bijgehouden, een goede kernel package heeft enorm veel out-of-the-box hardware-ondersteuning) als nadelen (een recentere driver op een oudere kernel gebruiken is zoveel gedoe dat een kernel upgrade meestal een aantrekkelijkere optie is)

(tot slot nog even dit; Linux LKMs kunnen ook rechtstreeks in de kernel meegecompiled worden, maar dit is tegenwoordig erg ongebruikelijk - buiten bepaalde embedded systemen kan ik me niet voorstellen dat dat nog ergens gebeurt)

Er is ook een gigantisch debat voor de modulaire kernel, QNX en Darwin (van MacOS) zijn meer microkernels. Dan heb je natuurlijk ook nog een hybride model (Windows heeft een hybride kernel), ...

Met QNX ben ik nauwelijks bekend, maar XNU (Darwin is het basis-OS, XNU de kernel) kan ik nauwelijks een microkernel noemen. Lang verhaal kort gebruikt XNU Mach (een echte microkernel), waarna ze voorzover ik weet nog steeds bijna alle functionaliteit in één address space stoppen omdat het anders te traag is.

... terwijl in de Windows kernel de HAL in feite niks kan, en zelfs NTFS een module is.

In Linux zijn filesystems ook modules. Op de computer waar ik nu achter zit is ext4 (het filesytem op mijn schijf) geladen als module

% lsmod | grep ext4
ext4 473802 3
crc16 12343 1 ext4
mbcache 17171 1 ext4
jbd2 82413 1 ext4

[roy-t]

Bedankt voor je super heldere uitleg! Het verschil tussen een microkernel en een monolitsche kernel kende ik wel. Maar deze vorm is een stuk logischer dan de 'een monolitische kernel heeft alles in de kernel' uitleg die ik wel eens gekregen heb.

[mzziol]

En dat is waar de zaken met Linux gaan verschillen; de Linux kernel heeft geen vastgelegde interne API

Misschien verstandig om erbij te zeggen: de *publieke* API van Linux is wel vastgelegd. Sterker nog, Linus gaat helemaal over de zeik als een developer die regel van kernel ontwikkeling aan zijn laars lapt.

[cyberstalker]

Dat is wel het idee bij Linux. Drivers worden zoveel mogelijk meegeleverd met de kernel. Uiteraard is er bij het compileren van de kernel nog altijd de optie om de bewuste driver niet mee te compileren, of deze als losse kernelmodule te compileren en zodoende de kernel klein te houden.

Het voordeel is dat je heel veel hardware gewoon in kunt pluggen en direct kunt werken, waar je bij Windows merkt dat je of moet wachten totdat de driver gedownload wordt, of je dat zelfs zelf moet gaan doen.

Onder Linux zijn heel veel drivers dus ook gewoon opensource, die blijven ook gewoon bruikbaar bij een update van het systeem. Je bent dus minder afhankelijk van hardwarefabrikanten. Er zijn slechts een handjevol fabrikanten die enkel closed source binary blobs uitbrengen die in de kernel kan worden geladen.

[Reactie gewijzigd door cyberstalker op 23 juli 2024 16:13]

[roy-t]

Wat vreemd. Dus eigenlijk is Windows meer 'lean-and-mean' door pas de driver te downloaden als deze nodig is . Wie had dat ooit gedacht.

Maar het is dus wel mogelijk om drivers los te gebruiken. Het is niet zo dat deze driver iets nodig hebben dat alleen in de kernel kan?

Dat drivers open-source zijn betekend natuurlijk niet dat ze blijven werken bij een nieuwe versie, iemand moet ze toch onderhouden

[i-chat]

wat je nu zegt klopt niet helemaal,

linux is juist veel lean and mean 'er dan windows omdat de drivers in de kernel zitten,

een voorbeeld: ik loop op het werk even naar de administratie, kun je dit even voor me uitprinten, NEE - dan moet je dit forumlier invullen en daar even een nummertje trekken en dan merk je wel of we dat kopietje voor je zullen maken ... (de windows manier, via api calls brigdes en overige extra code)...

dit iit linux, kun je even wat voor me printen, SURE! DONE!

linux word 'pas' bloated' als je alle drivers met je kernel mee compileerd maar als je die keuze wat hardware specifieker doet dan is het dus veel effcienter.

linux ondersteunt overigens beiden methodes (dus drivers waarvan je weet dat ze heel vaak zullen worden gebruikt, compileer je mee zodat ze sneller en efficienter worden geladen, maar drivers waar je niet zo zeker van bent voeg je toe als module, zodat ze je systeem niet belasten als je ze niet gebruikt, maar wel meer belasting vormen als je ze wel nodig blijkt te hebben,

in dat opzicht is het eigenlijk jammer dat er zo weinig distro's zijn die kernel compilation triviaal invoegen in het installatie-proces, want op heel wat systemen kan het best wel wat performance winst opleveren.

[Jaco69]

linux is juist veel lean and mean 'er dan windows omdat de drivers in de kernel zitten

Eh nee. Misschien wel maar zeker niet om die reden. Wat je zelf trouwens later ook zelf zegt.

linux word 'pas' bloated' als je alle drivers met je kernel mee compileerd

[Gepetto]

een voorbeeld: ik loop op het werk even naar de administratie, kun je dit even voor me uitprinten, NEE - dan moet je dit forumlier invullen en daar even een nummertje trekken en dan merk je wel of we dat kopietje voor je zullen maken ... (de windows manier, via api calls brigdes en overige extra code)...

Een ander voorbeeld

ik loop op het werk even naar de administratie, kun je dit even voor me uitprinten, JAHOOR - ik rij even de juist printer naar binnen en dan print ik het voor je, klaar! ... (de windows manier)

DAT KAN WEL, maar.... de printer die we daarvoor nodig hebben staat daar achteraan in die hele grote kamer, je zult wel eerst even die andere 200 printers opzij moeten schuiven, want die staan er ook omdat we graag elk type printer wat we maar nodig zouden kunnen hebben hier hebben staan. (de Linux manier)

[Reactie gewijzigd door Gepetto op 23 juli 2024 16:13]

[MBV]

Dat heeft alles met het open-source verhaal te maken. 'Vroeger', toen linux ontwikkeld werd, had geen enkele fabrikant zin om daar een driver voor te schrijven. Dat werd door hobbyisten zelf gedaan om hun eigen PC te ondersteunen. Vervolgens kon je bij het compileren van de kernel besluiten welke drivers wel en niet werden gebouwd. Als je als kernel-ontwikkelaars toch zelf de kernel moet schrijven, waarom dan moeilijk doen om de driver buiten de kernel te houden?

Daar is inmiddels iets aan veranderd (kernel bouwen doe je meestal niet meer zelf), maar het principe blijft bestaan. Er zijn wel alternatieven voor (voor o.a. closed-source NVidea drivers), maar die hebben voor de meeste producten geen meerwaarde.

Dat ze blijven werken heeft wel degelijk met open source te maken. Als een interface van de kernel verandert, compileert de driver niet meer zonder wijzigingen, en op 'dll-achtig' niveau kan de oude driver dan niet meer praten met de kernel. In veel gevallen is het even een regeltje code veranderen, en hij doet het weer. Ik weet dat dat vroeger een drama was met NVidea: dat was niet open source, en elke nieuwe kernel-versie ging die driver stuk.

[H!GHGuY]

Van alle antwoorden zit je er nog het dichtst bij.

Linux als open-source kernel is idd als hobby begonnen. Fabrikanten deden nog niet mee en iedereen moest wel reverse-engineeren of aan hardware datasheets raken.

De reden waarom dit grotendeels zo blijft is enerzijds door de open-source licentie en anderzijds door het release- en developmentmodel.
- Microsoft releaset elke zoveel jaar een update van het OS, al dan niet met een nieuw driver model. Het is dus per release erop of eronder. Daarom zijn ze verplicht om heel veel werk te steken in het afdekken van alle mogelijke use-cases. Daarbij werken ze ongetwijfeld samen met veel fabrikanten (kijk maar naar hoe DirectX ontwikkeld wordt) om aan iedereens noden te kunnen voldoen. Linux heeft quasi elke paar maand een release en heeft daarom die drang niet om in 1 keer iedereens problemen tegelijk op te lossen. Het gebeurt geregeld dat de 2de die een driver toevoegt voor een bepaalde klasse devices de eer krijgt om de vorige en nieuwe driver te abstraheren achter een mooie interne interface. De Linux kernel code is dus veel meer in beweging.
- Daarbij komt ook de licentie spelen: het is open-source, dus de code is out-there. Als de kernel dan zo 'vaak' verandert, waarom dan niet ìn de kernel zelf? Dan kan ze meteen mee veranderen waar nodig.
Het komt er dus op neer dat de licentie een ander business-model dicteert. In plaats van een closed-source driver onderhouden door de fabrikant, krijg je een open-source driver onderhouden door de community.
Het is dus ook in het belang van de fabrikanten om hun code in de mainline kernel te krijgen, anders hebben ze elke zoveel releases wel eens dat de code zo veranderd is dat hun driver niet meer werkt. Met ontevreden klanten en extra kosten tot gevolg. Het is dus letterlijk gratis "out-sourcing".

[Boy]

Yep, je kunt drivers als modules toevoegen (als ik de juiste termen gebruik)

Jaren Ubuntu gebruikt en het is wel lekker als je gewoon wat inplugt en het werkt zonder driver-shizzle. Maar als het dan niet werkt, moet je helaas vaak wel wat stunts uithalen (zoals een Epson printer/scanner waar je moet proberen wat dingen te installeren om uiteindelijk te kunnen scannen)

[Reactie gewijzigd door Boy op 23 juli 2024 16:13]

[mr_seeker]

Het grootste verschil met windows is dat de driver zo "generic" mogelijk wordt geschreven in linux op basis van de chip, en niet op basis van de producent. Elke "driver" wordt geschreven op een dusdanige manier dat de driver als een opslagapparaat werkt, en het programma alleen naar een bestand hoeft te schrijven/lezen.

Windows daarentegen heeft voor elk apparaat zijn eigen driver met zijn eigen functionaliteiten (dll). Dus een producent A die dezelfde chip gebruikt als producent B kan in theorie zijn eigen versie van de dll meesturen door simpelweg het laatste nummer van het Device-ID aan te passen. Dit levert altijd leuke zaken op bij een driverconflict...

Source: http://www.cs.ru.ac.za/re...atic/papers/oscomposr.pdf

Het voordeel van Linux die alles onder de kernel plaatst is dat ik onder linux met een "generic screen" altijd via linux de boel kan opstarten, maar als ik van de gehele capaciteiten van de intel chip gebruik wil maken een speciale driver nodig heb. Omdat AMD de drivers open-source maakt en deze drivers in de kernel zet kan men makkelijker debuggen en fouten opsporen. Het aloude Windows vs Linux verhaal geldt namelijk ook voor NVidia vs AMD...

[Jorick]

Linux kernel kun je ook prima lean-and-mean maken door een eigen kernel te compilen en dan alleen de broodnodige modules/onderdelen mee te nemen die nodig zijn om op je systeem te draaien. Dat de Linux kernel veel drivers bevat wil niet zeggen dat ze ook geladen worden natuurlijk, als een systeem opstart wordt er 'geprobed' naar hardware en dan worden de geschikte modules (mits aanwezig) geladen.

Drivers hebben overigens ook steeds vaker een (closed-source) firmware component dat eerst ingeladen moet worden voordat een driver z'n werk kan doen. In mijn ervaring is het vooral de firmware die nogal eens voor problemen zorgt en een goed werkende out-of-the-box ervaring in de weg staat. Dit komt mede omdat de firmware blobs zijn waar geen source-code van beschikbaar is en ook niet zomaar meegeleverd/opgenomen mogen worden in de kernel wegens licentie-technische redenen. Dit maakt het voor ontwikkelaars van open-source software/drivers steeds moeilijker om werkende drivers te ontwikkelen. Goed voorbeeld is (of was) bijvoorbeeld de Nouveau driver i.c.m. de Maxwell kaarten van nVidia die pas sinds kernel versie 4.1 out-of-the-box 'werken'. Voor 4.1 was je eigenlijk aangewezen op de proprietary drivers van nVidia zelf en die worden door distro's vaak niet standaard meegeleverd of ondersteunt.

[dmantione]

AMD behoorde dus tot het selecte groepje van fabrikant die binaire blobs aanbood die gebruikers in de kernel moesten laden. De voornaamste reden voor een videokaartfabrikant om dat de doen is dat de driver een belangrijk deel van zijn product is: Door de broncode openbaar te maken worden concurrenten geholpen.

Er bestaan echter ook openbrondrivers voor de Radeon-kaarten, die weliswaar trager zijn en minder functies hebben, maar vanwege de open broncode door iedere Linuxdisttributie meegeleverd worden en daarmee plug & play werken. Die open drivers zijn door de gemeenschap geschreven op basis van door AMD aangeleverde documentatie. Omdat AMD er belang bij heeft dat nieuwe kaarten direct door de open drivers worden ondersteund is AMD over tijd gaan meeprogrammeren aan die open drivers.

Dat is voor AMD echter dubbel werk. Vandaar de AMDGPU-driver. Dit is een kerneldriver die alleen de strict noodzakelijke functies uitvoert. Omdat er vrij weinig technologie in zit kan AMD de broncode daarvan makkelijk vrijgeven. De bulk van de driver zal in userspace draaien. Dat was op zich al zo bij de huidige drivers, het zal bij AMDGPU nog een veel groter gedeelte zijn.

Van zowel de open driver als AMD's eigen binaire drivers zal alleen het userspace-gedeelte overblijven en dat wordt aangepast om van AMDGPU gebruik te maken. Het resultaat is dat het voor de binaire driver makkelijker wordt hem te installeren (hij hoeft niet langer voor je kernel gecompileerd te worden met alles wat daarbij mis kan gaan) en voor de open drivers ondersteuning voor nieuwe kaarten sneller kan worden toegevoegd, waarbij AMD het lastige deel van het werk zal doen.

[Blokker_1999]

Ik snap eigenlijk niet waarom de AMD GPU driver onderdeel uit maakt van de kernel. Betekend dit dat je zonder kernel ondersteuning niet een nieuwere videokaart zou kunnen gebruiken? Het is toch ook niet zo dat alle hardware standaard door de kernel ondersteund moet worden om te functioneren? Dat is toch juist het idee van drivers (die zelfs in user-mode kunnen draaien zodat een slechte driver niet het hele systeem plat trekt). Of is dat alleen in Windows zo?

Drivers moeten altijd gecompileerd worden voor een specifieke kernel. Je kan er dan ook voor kiezen om ze ofwel in 1 keer mee in te bouwen (en ze dus altijd te laden, zelfs als je ze niet nodig hebt, of je kan ze als module ter beschikking stellen waardoor ze enkel geladen worden als er nood aan is (zoals altijd in Windows gebeurd).

[MBV]

Als ze zijn mee-gecompileerd met de kernel worden ze zeker niet automatisch geladen. Sterker nog: Ubuntu levert niet alle drivers mee. De libraries (vergelijkbaar met DLL's) voor NVidea, AMD enzovoort moeten apart geinstalleerd worden.

[maikoool]

Dat komt omdat nvidia en amd haar drivers niet onder een licentie willen vrijgeven die compatible is met de Linux kernel, en daarom niet standaard worden meegeleverd. De drivers die ubuntu je aanbiedt zijn deze non-free drivers van de fabrikant.

De Linux kernel bevat echter gewoon radeon/nouveau drivers, de open source varianten van de non-free versies, en ook bij ubuntu zitten deze in de standaard kernels.

[bouwfraude]

Zie het positief. Er zijn tijden geweest dat het hebben van een ATI/AMD GPU zeer problematisch was bij Linux. Bij iedere update van de kernel had je geen grafisch beeld meer. Nvidia deed het beter ook al was de driver niet open.
Gelukkig zijn de interne intel GPU's redelijk vlot tegenwoordig.

[Verwijderd]

Hoe zit dat met Nvidia en drivers?
Vooralsnog ben ik amper instaat geweest normaal te booten naar de GUI van de installatie cd/usb i.c.m een Nvidia kaart.
Resulteert bij mij altijd in zwart witte blokken of één grote puinhoop op het beeld, was het niet voor dan was het wel na 1st boot.
Was het wel gelukt dan enkel over VGA, wat ik direct weer kon verkrachten met het installeren van de closed-source Nvidia drivers, en zo weer terug bij af was.
Met een budget GeForce 6200 was dit al het geval, nooit echt een oplossing voor gevonden, dan maar cli.

Zo 2 verschillende generaties AMD kaarten verder zonder problemen kunnen draaien.
Met het idee dat het onderhand geen probleem meer zou zijn toch maar een GTX750 gehaald voor mn huidige PC. gelijk even gekeken of linux er zo op wou booten, maar helaas. (@AMD 990FX alsook op een Intel 1366 i7 systeempje).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:13]

[Jorick]

Hangt van je videokaart af en hoe goed deze door de Nouveau drivers ondersteund wordt. In het geval van de GTX750 is dit tot versie 4.1 van de Linux kernel problematisch geweest omdat de firmware op een omslachtige manier ingeladen moest worden.

Als je een live- of installaltie-CD/USB wil draaien op je pc moet je nomodeset meegeven als kernel parameter zodat je ten minste beeld krijgt al is dit beperkt tot VESA output (lage resolutie en weinig kleuren). Vervolgens kun je dan via de GUI of via een terminal de proprietary closed source driver van nVidia installeren. Voor Ubuntu is hier een howto te vinden.

Een andere optie is om de driver handmatig te downloaden en te installeren wat zelfs werkt in de live-CD/USB modus omdat je niet hoeft te rebooten. In geval van Ubuntu gaat dat als volgt:

• boot je live-CD/USB met kernel parameter nomodeset
• Download de driver van de nVidia website en geef de drivers uitvoer-permissie: chmod +x NVIDIA-Linux-xxx.run
• Switch naar console: CTRL+ALT+F1
• Stop de displaymanager: sudo service lightdm stop
• Blacklist de nouveau driver door de regel blacklist nouveau toe te voegen aan het bestand /etc/modprobe.d/blacklist. Dit voorkomt dat je na een reboot weer de nouveau drivers geladen worden en je geen beeld krijgt. Als je een live-CD/USB draait kun je deze stap overslaan.
• cd naar de map waar je de driver hebt gedownload
• Start de installatie van de driver: sudo ./NVIDIA-Linux-xxxx.run en volg de instructies. Om te voorkomen dat je bij een permanente installatie bij iedere kernel update je handmatig de nVidia drivers weer moet installeren is het verstandig DKMS in te schakelen. Voor een live-CD/USB kun je dit overslaan.
• Als de installatie voltooid is kun je controleren of de nvidia kernel geladen is: lsmod | grep nvidia.
• Start de displaymanager: sudo service lightdm start. Als alles goed gaat switch je automatisch naar het loginscherm van Ubuntu en heb je volledige 2D/3D ondersteuning van je videokaart.

Dat je AMD kaarten wél werken komt omdat de open-source drivers voor AMD videokaarten beter zijn, echter bieden deze niet dezelfde prestaties als de proprietary drivers die AMD zelf levert.

[Reactie gewijzigd door Jorick op 23 juli 2024 16:13]

[Verwijderd]

Zojuist even Xubuntu 14.04 x64 Live op een reserve laptop (BTO W370SS met een GTX860M) van mijn werk getest, zonder problemen.
( Gelijk even van de gelegenheid gebruik gemaakt om chntpw de vergeten taak van een oud-collegea op te laten knappen ).
De laptop (BTO W170ER met een GTX650M) waar ik zelf op werk, ook geen problemen.

Betreft de geluidsproductie was de GTX750 STRIX dus iigv. een goede keuze

Bedankt voor je duidelijke uitleg / workaround.
Ik zal eens kijken of ik daar mee die GT6200(pci) een actiever leven kan gunnen op het i7 servertje.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 16:13]

[hackerhater]

Hmmm vreemd.
ik heb zelf een redelijk recente NVidia kaart erin zitten en beeld had ik altijd wel.
Crappy resolutie en performance, maar beeld altijd wel over HDMI.
install => boot => updates draaien => reboot => NVidia driver erop => X restart => volle resolutie.

Nu is dit wel pas iets van de laatste jaren.

[Reactie gewijzigd door hackerhater op 23 juli 2024 16:13]

[Awesomehobo]

Interessant om te zien dat, naast de optimalisatie van meerdere soorten hardware, ook het audiosysteem is gewijzigd / geüpgraded.
Vooral het gespecificeerde gedeelte m.b.t. Alienware headsets

[Verwijderd]

Dat hebben ze zeker gedaan voor Steam OS, het Linux gameplatform.

[afraca]

Voor eenvoudige mooie overzichten kijk ook op:
http://kernelnewbies.org/LinuxChanges

Duurt nog eventjes voor die geupdate is maar dan weet u alvast waar u terecht kan

[XVI]

Zeer blij met de blacklisting van (alle populaire?) Samsung SSD's in libata en de mogelijkheid om queued trim via een kernel parameter geforceerd uit te schakelen.
Hopelijk kan ncq dan weer aan zonder dat trim de boel crasht (i.v.m. de recente firmware upgrade van m'n Samsung 840 evo).

[sfranken]

En voor de mensen met een semi-courante nvidia kaart: de Nouveau driver krijgt ook support. Ik zit namelijk zelf met het issue dat m'n GTX 750 niet helemaal soepel ondersteund word op Fedora met 4.0.4 als kernel. Op 4.1 wel, maar dat is een Rawhide (Fedora development) kernel en die is, uh, niet bepaald stabiel.

Heb het dus maar opgelost door de closed-source driver van nvidia te installeren, al wil ik wel weer terug naar nouveau, vanwege de toegevoegde grafische pracht en praal tijdens het booten wat nu een beetje weg valt.

[vliegnerd]

Het artikel kan duidelijker:

"... het wel de release candidate 3.11-rc1 verslaat. Daarbij was de toevoeging van het Lustre-bestandssysteem de belangrijkste reden van het grote aantal toegevoegde regels. "

Nu lijkt het net of Lustre de belangrijkste reden van het grote aantal toegevoegde regels in 4.2-rc1 is, maar dat klopt niet. Dat was 3.11-rc1.

"Daarbij" kan vervangen worden door: "In die release ...".

"... het wel de release candidate 3.11-rc1 verslaat. In die release was de toevoeging van het Lustre-bestandssysteem de belangrijkste reden van het grote aantal toegevoegde regels. "

[CAPSLOCK2000]

Er lijkt nogal wat onduidelijkheid te bestaan over wat het betekent als een driver "in of bij in de kernel zit" .
Als een driver "in de kernel zit" dan wordt daar over het algemeen niet mee bedoelt dat deze altijd geladen is. Drivers zijn losse files die, net als onder Windows, geladen worden als het nodig is. Er wordt wel bedoelt dat de driver wordt geschreven en onderhouden door hetzelfde team als de rest van de kernel. Dat heeft als voordeel dat er veel sneller kan worden ontwikkelt. Je hoeft geen rekening te houden me duizenden hardwarefabrikanten die drivers moeten onderhouden. Alles kan direct door het kernelteam worden gedaan waardoor er veel kleine stappen kort achter elkaar worden genomen in plaats van eens in de drie jaar een grote stap.

Onder Windows is het onderscheid veel stricter. Je hebt Windows van Microsoft en je hebt drivers en die worden door de hardwarefabrikanten geschreven. Onder Linux bestaat dit verschil wel maar is het veel minder belangrijk. Omdat alle code vrij is heeft het geen zin dat iedere fabrikant z'n eigen drivers schrijft en op z'n eigen website zet. Bijna alle drivers worden gezamelijk beheerd en gepubliceerd. Onder Linux heeft men het dus niet over "de kernel" enerzijds en "de drivers" anderzijds. Dat wordt als één geheel gezien. Alleen bij closed source drivers (zoals die van NVidia) moet je die drivers apart ophalen van de website van de fabrikant en zelf installeren.

[CAPSLOCK2000]

Dat Lustre nu in de kernel zit is een grote stap voor dat project. Het bestaat al meer dan 10 jaar maar het komt nu pas in de standaard kernel.

[AndrewF]

Lustre zit al sinds 3.11 in de linux kernel. Die versie werd gereleased op 2 september 2013.

[1] http://kernelnewbies.org/Linux_3.11