Linux-kernel 4.9 komt uit met grootste release tot nu toe

Linus Torvalds heeft groen licht gegeven voor de release van versie 4.9 van de Linux-kernel. De release, die volgens Torvalds 'de grootste tot nu toe' is, brengt verschillende veranderingen met zich mee, waaronder bredere ondersteuning voor AMD Radeon-gpu's.

Zo voegt de nieuwe versie van de kernel experimentele ondersteuning toe aan de amdgpu-driver voor Southern Islands-varianten, oftewel de HD 7000-serie. Daarnaast is deze versie uitgebreid met ondersteuning voor virtual displays. Andere veranderingen zijn de toevoeging van ondersteuning voor een groter aantal ARM-apparaten, waaronder de Raspberry Pi Zero, de LG Nexus 5-smartphone en de Netgear WNR854T-router.

Bovendien maakt Greybus deel uit van de release. Dat is een subsysteem dat gebruikt zou worden door de modulaire Project Ara-telefoon van Google, als de zoekgigant niet had besloten om dat project stop te zetten. Phoronix schrijft dat het subsysteem ook gebruikt moet worden in een Motorola-toestel. Versie 4.9 van de kernel brengt ook ondersteuning voor geheugenbescherming met zich mee door middel van memory protection keys.

Volgens Torvalds is de nieuwe release de grootste tot nu toe als gekeken wordt naar het aantal commits. Een van de redenen daarvoor is de Greybus-ondersteuning. Torvalds voegt daaraan toe dat de release er voor de rest normaal uitziet, met meer dan twee derde aan drivers. Phoronix meldt dat de kernel inmiddels 22,3 miljoen regels code bevat, inclusief tools en documentatie. Om de kerstviering niet te verstoren, heeft Torvalds de merge window voor release 4.10 vastgesteld op 23 december.

Reacties (78)

[ExIT]

Ondanks de woordenwisseling laatst (nieuws: Linux-onderhouder weert AMD-drivercode uit kernel) dus wel AMD code. Alleen niet de code die in dat artikel besproken werd. Dat geeft toch wel aan dat het inderdaad ging om huisregels en niet om een AMD boycot om wat voor reden dan ook. Mooi om te zien dat de emotie bedaard is.

[Verwijderd]

Ondanks de woordenwisseling laatst (nieuws: Linux-onderhouder weert AMD-drivercode uit kernel) dus wel AMD code. Alleen niet de code die in dat artikel besproken werd. Dat geeft toch wel aan dat het inderdaad ging om huisregels en niet om een AMD boycot om wat voor reden dan ook. Mooi om te zien dat de emotie bedaard is.

Het zou heel erg dom zijn van de Linux kernel developers om een fabrikant te boycotten
Het gaat de linux kernel developers om een brede ondersteuning van hardware maar wel met een bepaalde minimale kwaliteit. Dat laatste was het probleem t.a.v. de AMD genoemde code.

[latka]

Moet je eens kijken naar het Linus Torvalds "Fuck you Nvidia" filmpje. Linux is zo schaalbaar omdat de code precies doet wat het moet doen en niet meer. Geen rommel in de kernel dus en een stabiele API naar buiten toe. Code van derden moet ook via deze review voordat het mee mag in de reguliere releases. Nvidia doet dit niet (binaire drivers) en AMD ook niet (dikke grote blob met code en een dikke doei, zoek het maar uit).
Microsoft heeft dit ook gedaan met de HyperV code (hier is de code, zoek het maar uit). Was er toch bijna weer uitgegooid toen bleek dat er niemand was die het onderhield. MS ook niet, dus dan wordt het geschrapt. Fabrikanten worden dus wel degelijk onder druk gezet normaal te werken ipv. de quick fix te kiezen.

[Qalo]

Ik vind het de enige en juiste manier van werken. Er moet een stevige controle op gehouden worden, en de Linux-developers moeten degenen zijn die bepalen wat er in de Linux kernel gepropt wordt, niet één of ander commercieel bedrijf die hun code over de schutting gooien met een houding van "God-zegene-de-greep".

Men kan er commentaar op hebben dat de kernelontwikkelaars "zeikerds" zijn, maar om te voorkomen dat het één grote bende wordt is dit de enige manier. Jammer voor AMD en weet ik veel welke partijen, maar is de code niet oké, dan heb je het maar te slikken dat je het opnieuw moet doen en het op een dusdanige manier aanleveren dat het wèl geïmplementeerd kan worden.

Niemand is gebaat bij een Linuxkernel die vol zit met bende. Vervelend dan dat bij sommigen de allernieuwste hardware niet ondersteund wordt, maar dat is dan maar even zo. Het belang van een goede, stabiele en degelijke kernel is groter dan de wens van de klager(s).

[i-chat]

ik ben het met je eens dat de quickfix geen doel opzich mag zijn, maar als waar is wat amd claimt en ze vooral haast hebben om het werkend te krijgen heb ik daar begrip voor, ik zou stellen dat een quickfix tijdelijk best moet kunnen zolang er dan vervolgens bij elke release verbering te zien is... en zolang die quickfix geen andere fucties belemmerd.

als die controversiele amd code nu toch in zit is dat alleen maar goed voor de eindgebruiker en is het aan AMD om nu als de bliksem verder te werken aan waardige opensource drivers die wel permanent gebruikt en doorontwikkeld kunnen worden.

[DutchKevv]

Denk dat ze ook wel moesten.. Linux moet het (commercieel gezien) hebben van zijn 'openlijke kern', en als een groot bedrijf als AMD daar kladder overheen begint te smeren, kan dat veel kwaad doen aan het imago.

Desalniettemin ben ik blij dat het inderdaad bekoeld is. Videokaart drivers etc kunnen toch wel vaak een doorn in het oog zijn met linux. De beter die relaties, des te beter voor ons

Hier het (net zo scherp getinte) tegenantwoord van AMD https://lists.freedesktop...2016-December/126701.html

edit:

link toegevoegd

[Reactie gewijzigd door DutchKevv op 24 juli 2024 04:13]

[84hannes]

Linux moet het (commercieel gezien) hebben van zijn 'openlijke kern',

Linux moet commercieel gezien helemaal niets, dat is de kracht van Linux. Niet morgen al de nieuwste grafische kaart ondersteunen, maar over 10 of 20 jaar nog steeds goed onderhoudbaar zijn. Als je nieuwe functionaliteit zo snel mogelijk (en ten koste van de toekomst) in je besturingssysteem gepropt wilt hebben dan ga je voor een commercieel OS.
Maar geen stress, dit wordt er wel weer uitgesloopt als het echt zo ononderhoudbaar is als eerdere artikelen deden vermoeden.

[DutchKevv]

Dat snap ik.. Maar dat neemt niet weg dat Linux een doelgroep heeft. En die doelgroep is een groep fabrikanten en users die (vaak) links of rechts om iets met linux doen omdat het open is, en/of omdat er tools in zitten, omdat het open is...

Ben met je eens dat linux vooral stabiel moet zijn, maar door geen moderne hardware te ondersteunen schieten ze zich zelf ook echt wel redelijk in de voeten. En al zou dat meevallen, een roepende AMD dat linux k*t is, willen ze ook echt niet.

En omgedraaid als jij het aller stabielste wil, dan moet je gewoon niet een kernel pakken die 2 dagen oud is.. Maar een stabiele kernel van een paar maanden oud.

[Reactie gewijzigd door DutchKevv op 24 juli 2024 04:13]

[FreezeXJ]

Ze willen met alle genoegen moderne hardware ondersteunen, maar als een fabrikant even 100.000 regeltjes code 'dumpt' om daarmee zijn Windows-drivers op Linux te kunnen gebruiken dan zijn ze daar niet zo dol op. Al die code is nogal ondoorzichtig, en zoals Airlie al aangaf, abstraction layers willen ze niet. Dat maakt het een chaos.

Goede en nuttige code is van harte welkom natuurlijk, en de huidige drivers groeien als kool nu AMD veel meer openheid geeft. Overigens heeft ook NVidia genoeg hooks in de kernel zitten, waar hun eigen gesloten code dan tegenaan kletst.

[Caelorum]

Ze willen met alle genoegen moderne hardware ondersteunen, maar als een fabrikant even 100.000 regeltjes code 'dumpt' om daarmee zijn Windows-drivers op Linux te kunnen gebruiken dan zijn ze daar niet zo dol op. Al die code is nogal ondoorzichtig, en zoals Airlie al aangaf, abstraction layers willen ze niet. Dat maakt het een chaos. [...[]

Van wat ik er van mee heb gekregen uit de mailing list was de code op zichzelf nog niet eens een probleem. Alleen de werking intern is compleet anders dan de overige drivers en dat willen ze niet meer. Het wordt daardoor namelijk lastig om er even snel in te duiken. Zelfs de abstracties vonden ze niet eens een probleem alleen de manier waarop het is gedaan.

[FreezeXJ]

Om Airlie direct te quoten: "No HALs. We don't do HALs in the kernel." waarbij HAL staat voor Hardware Abstraction Layer. Da's ongeveer precies wat deze AMD-patch (voor hun Display Abstraction Layer, die nu DisplayCore heet) is, dus vandaar dat ie ook geweigerd is.

Zijn uitleg spreekt verder voor zich.

[Reactie gewijzigd door FreezeXJ op 24 juli 2024 04:13]

[MrFax]

Volgens mij heeft deze code niets te maken met de code voor de HD7000 drivers, die al weken geleden is toegevoegd, anders zou het niet nu al in de mainline/stable release zitten.

[Caelorum]

Ja, maat iets later kwam hij daar al deels op terug, dus tja..

[84hannes]

En omgedraaid als jij het aller stabielste wil, dan moet je gewoon niet een kernel pakken die 2 dagen oud is.. Maar een stabiele kernel van een paar maanden oud.

Dan heb ik over twee maanden hetzelfde probleem: meuk in de kernel die daar niet in thuis hoort.

[DutchKevv]

Daar heb je wel een goed punt..

Ik ga/ging er vanuit (en ook ergens gelezen) dat het een race tegen de klok is om nieuwe GPU hardware te ondersteunen op release date op linux.. En vandaar dat het geen glory code is. Waarna zoals je terug leest in hun mails ook de discussie begint over post clean-up merges, die de ene partij de moeite waard vind en de andere niet..

Vraag is wellicht of het de moeite waard is om eerst met mindere kwaliteit code toch de nieuwste hardware te ondersteunen, en dan na verloop van tijd de code te verbeteren..

Snap linux dan eigenlijk ook wel inderdaad.. Het is vragen om problemen..

[JackBol]

De Linux kernel (alhoewel monolitisch vanuit executie oogpunt) is redelijk modulair mbt. de code die je in de kernel laadt. (type voor de grap eens 'lsmod').

[Reactie gewijzigd door JackBol op 24 juli 2024 04:13]

[BeosBeing]

Niet morgen al de nieuwste grafische kaart ondersteunen, maar over 10 of 20 jaar nog steeds goed onderhoudbaar zijn.

Zelfs nu al vindt ik dat veel oudere hardware niet meer goed ondersteund wordt. Dat licht echter niet zozeer aan Linux, maar aan het userland daaromheen, met name dat mbt tot de X-Windows-omgeving. Ik ben al diverse laptops tegen gekomen waar Debian en Debian-afgeleiden in prinpipe prima op installeren maar waar daarna het scherm na het starten van X nog twee tinten kent, Zwart (0,0,0) en UltradonkerGrijs (1,1,1) . Met goed kijken kun je dan zien dat er inderdaad een beeld gevormd wordt, maar bruikbaar is het zeker niet.

Gezien ik geen tijd heb om te achterhalen waar dat de oorzaak zit (kennis ook niet kunnen bijhouden) heb ik het er dan maar bij gelaten.

Overigens vind ik het wel typisch dat men nu met ondersteuning komt voor de HD7000 serie terwijl AMD die op het Windows-platform al end-of-life/legacy heeft verklaard.

Ook wel jammer dat men bij zo'n grote stap niet ook overstapt op versienummer 5.0

[Reactie gewijzigd door BeosBeing op 24 juli 2024 04:13]

[FreezeXJ]

Ouder spul wordt ondersteund als iemand die ondersteuning schrijft. Voor iets als de 7k-series is genoeg belangstelling, en daar doen de open-source-drivers hun werk uitstekend. Voor rare laptop-GPUs met nog vreemdere drivers die niet overweg kunnen met de standaard MESA-drivers houdt het snel op. De gebruikersgroep is minimaal, de benodigde moeite is groot.

Overigens is de stap naar 5.0 nog een maatje meer, we zijn nu al een minor versie omhoog, dat gebeurt ook niet wekelijks. Het is al een stuk beter dan 2.8.30build35 wat we nog niet heel lang geleden hadden.

[BeosBeing]

Voor rare laptop-GPUs met nog vreemdere drivers die niet overweg kunnen met de standaard MESA-drivers houdt het snel op.

Het ging helemaal niet om rare laptops. Standaard merken/modellen zoals van Acer (ik weet het modelnummer niet meer uit mijn hoofd, ik dacht de 5736Z, in ieder geval toevallig hetzelfde model als mijn vorige werkgever op naar alle leerlingen van een school hier heeft geleverd ( en dat ging dus om ongeveer 120 stuks) maar ook desktops, o.a. een Dell 170L (intel gpu)en een PC met een nVidia Geforce FX5200 en andere goedkope laptops met intel gpu's.

De gebruikersgroep is minimaal, de benodigde moeite is groot.

De gebruikersgroep is gigantisch maar het aandeel daarvan dat Linux installeert is minder dan minimaal. Men kan het zelf niet. Als dan ook nog blijkt dat na installeren het niet werkt, geeft men het heel snel op.

Wie bewust voor Linux (of xBSD) kiest, gaat meestal ook voor iets duurdere hardware.

[Reactie gewijzigd door BeosBeing op 24 juli 2024 04:13]

[opdiefiets]

Maar verwachten jullie nu dat AMD gaat stoppen met ondersteuning voor Linux, of in ieder geval met opensource drivers? Als het niet gewaardeerd wordt door de linux-gemeenschap dan is het toch zonde om hier resources aan te spenderen?
Ik snap sowieso niet helemaal waarom dit onderdeel moet zijn van de kernel, dit kun je toch net zo goed met drivers regelen? En die kunnen voor Linux toch net zo goed closed-source zijn? Ik begrijp dat het tegen het zere been van enkele dogmatici is, maar daar hoef je je niet perse iets van aan te trekken.

[84hannes]

Het is maar een theorie, maar ik heb jarenlang de closed source drivers van nVidia gebruikt. Sinds ik de Intel APU drivers, volgens mij wèl open source, gebruik is mijn systeem veel stabieler. De kwaliteit van open source drivers wordt naar mijn idee veel beter in de gaten gehouden (wellicht zoals de meesten van ons hun kamer opruimen als er visite komt).

[Verwijderd]

Als je nieuwe functionaliteit zo snel mogelijk (en ten koste van de toekomst) in je besturingssysteem gepropt wilt hebben dan ga je voor een commercieel OS.

Dat is niet eens nodig. Er zijn genoeg distros (een van de bekendste is dan Arch I guess) die het nieuwste van het nieuwste er vlot doorheen trappen.

[i-chat]

stierenpoep linux word niet gemaakt op een zolderkamertje door alwetende nerd, die daten zjn al zeker 10 jaar voorbij... linux is het product van vele winstgevende bedrijven die samen proberen een goed werkend systeem te houden waar iedereen iets aan heeft en iets mee kan... waarbij samenwerken commercieel beter te verantwoorden is dan alleen gaan...

dat maakt even goed dat linux niet zonder gpu drivers kan voor een heel aantal van zijn toepassingsgebieden... de problemen met AMD zijn een probleem voor talloze bedrijven zoals redhat, cononical en anderen...

[CH4OS]

Ik denk dat die code niet in 4.9 had gekomen, zo kort voor de release van kernel 4.9. Er had immers ook uitgebreid getest moeten worden, wat je niet even snel tussendoor kan doen.

[w3news]

Wat niet stabiel is, wordt niet meegenomen.

Linus:
I suspect we all want a nice calm winter break, so if your
stuff isn't ready to be merged early, the solution is to just not
merge it yet at all, and wait for 4.11.
https://lwn.net/Articles/708766/

[CH4OS]

Gaat mij er meer om, dat in een dergelijk korte tijdspanne een driver niet meegenomen kan worden, ook al zou de code wél gemerged zijn. De geweigerde code van onlangs zou dan dus sowieso pas verschijnen in 4.10 op zijn vroegst.

[Verwijderd]

Zou straf zijn dat ze daar een boycot op willen zetten, zoals in het andere artikel staat is het onderhoud de reden van het niet toevoegen van die specifieke code.

[ExIT]

Eens. Het ging om Linux-huisregels. Toch was het best een verhitte discussie tussen twee belangrijke mensen voor de Linux-AMD samenwerking. Dave Airlie is al 10 jaar eindverantwoordelijke voor de kernel. Toen Dave emoties op papier schreef en Alex in reactie ook een dreigende toon aannam werd het even ongemakkelijk.

[Reactie gewijzigd door ExIT op 24 juli 2024 04:13]

[Toettoetdaan]

Zo voegt de nieuwe versie van de kernel experimentele ondersteuning toe aan de amdgpu-driver voor Southern Islands-varianten, oftewel de HD 7000-serie. Daarnaast is deze versie uitgebreid met ondersteuning voor virtual displays.

Ik dacht dat deze veranderingen voor 4.10 op de planing staan: http://www.phoronix.com/s...on-AMDGPU-Fixes-4.10-Soon
EDIT:
Zit er dus gewoon in: http://www.phoronix.com/s...m=linux-49-features&num=1

[Reactie gewijzigd door Toettoetdaan op 24 juli 2024 04:13]

[Jerie]

Alleen niet de code die in dat artikel besproken werd.

Dat was 100% zeker niet in 4.9 beland, dat was voor 4.10 bedoeld (waarbij merge window sluit op 23 december en dus daarna naar RC status gaat). Toen AMD vroeg of die patch gemerged kon worden begin december, zat 4.9 al lang en breed in RC status.

[MadEgg]

Was leuk geweest om even uit te leggen wat Greybus nou precies is. Het het hier gevonden:

Overall, it's a tiny stand-alone driver subsystem, only 37k lines, that
implements a protocol which allows for "generic" cameras, audio devices,
and other class type devices, as well as a bridged "physical" layer
protocol to talk to serial, spi, uart, pwm, gpio, i2c, and even USB host
controllers. Included here is a USB bridge host controller driver that
interacts with a USB device that converts USB data to Unipro data,
allowing any system to talk to a Unipro platform (no special SoC
interface required.)

Vooral leuk voor embedded devices dus. De AMD drivers zijn weer interessanter voor de desktop, al mist de RX 460/470/480 support helaas nog. Toch is AMD goed bezig met het open sources van hun drivers, de driver support voor ouderen AMD kaarten met de open source drivers is wat mij betreft echt fenomenaal. Hopelijk wordt dit ooit nog uitgebreid naar de nieuwste GPU's van AMD, en gaat nvidia ook eens overstag. Maar dat zal helaas nog wel even duren.

[Just3]

Polaris GPU (i.e. RX 460/470/480) support met de AMDGPU driver zit sinds versie 4.7 in de Linux kernel.

[MadEgg]

Oh echt? Nice. Ik meende dat je daarvoor nog steeds een proprietary driver nodig had. Dan zijn ze verder dan ik dacht!

[wpoely86]

Je hebt de keuze: er is de amdgpu driver zoals in de mainline kernel sinds 4.7 of de amdgpu-pro driver van de AMD website. Die laatste is de driver zoals hij de kernel zit maar met DAL/DC, volledige OpenCL ondersteuning en nog een paar extras.

Als je een AMD kaart wilt gebruiken met bv RHEL 6.x dan heb je ook die amdgpu-pro driver nodig (AMD heeft hem gebackport).

[Sando]

De gecompileerde kernel heeft veel weg van een blockchain. Hij wordt steeds groter. Vroeger moest je alle modules bij elkaar zoeken die je nodig had. Tegenwoordig zit het meeste al in de kernel en moet (kan) je handmatig compileren om spullen uit te zetten die je niet nodig hebt. In theorie. Want Linux distro's shippen gewoon dat hele ding als binary. Meestal in een paar varianten als kernel-generic en kernel-realtime, maar wel gewoon met alles.

Wat betekent dat voor de efficiëntie van de kernel?

2001: 3 MB
2006: 8 MB
2012: 15 MB
2016: (kan geen bron vinden)

[Reactie gewijzigd door Sando op 24 juli 2024 04:13]

[Maurits van Baerle]

De vraag is of je efficiëntie wel moet meten in absolute eenheden als MB's. Zou het niet logischer zijn om ze te meten als percentage van bijvoorbeeld de gangbare hoeveelheid RAM bij het uitkomen?

3 MB was in 2001 een stuk groter dan 15 MB was in 2012 bijvoorbeeld. Zo gezien neemt de kernel juist steeds minder resources in beslag.

[N8w8]

Klopt, en daarnaast: Juist omdat we tegenwoordig zoveel RAM hebben, permitteren de distro's het zich om er meer in te stoppen.
Zo heeft de standaard Debian kernel Xen extensies, terwijl vrijwel niemand dat gebruikt. Vroeger moest je daar een aparte kernel voor installeren.
Waar het werkelijk om draait, is hoeveel groter de kernel tegenwoordig is, bij dezelfde features.

[dupondje]

De reden hiervoor was anders dacht ik.
De Xen code was lange tijd een 'patch' die bestond naast de mainstream kernel.

Daardoor was er ook een andere package voor de xen kernel.

Aangezien dat nu merged is en Xen deel uitmaakt van de huidige kernel, is dit maar 1 package

[AJediIAm]

Klinkt logisch. Ik kan me voorstellen dat leveranciers van embedded devices een wat kleinere kernel willen leveren.

Weet iemand of de raspberry pi distributies een uitgeklede of volledige kernel hebben?

[Verwijderd]

De gecompileerde kernel heeft veel weg van een blockchain. Hij wordt steeds groter. Vroeger moest je alle modules bij elkaar zoeken die je nodig had. Tegenwoordig zit het meeste al in de kernel en moet (kan) je handmatig compileren om spullen uit te zetten die je niet nodig hebt. In theorie. Want Linux distro's shippen gewoon dat hele ding als binary. Meestal in een paar varianten als kernel-generic en kernel-realtime, maar wel gewoon met alles.

Wat betekent dat voor de efficiëntie van de kernel?

2001: 3 MB
2006: 8 MB
2012: 15 MB
2016: (kan geen bron vinden)

Bij alle distro's hoef je geen kernel code te compileren. Het broodnodige zit in de gecompileerde kernel de rest wordt als module geleverd.
Ik ken geen enkele Linux distro waar dit niet het geval is.

Ik compileer zo goed als nooit meer een kernel zelf omdat de noodzaak ontbreekt.

[GuntherDW]

https://www.gentoo.org/ , http://www.funtoo.org/Welcome
of het iets minder populaire/long term beheerbare http://www.linuxfromscratch.org/

Je hebt in Gentoo wel het "genkernel" script als je een meer live-cd achtige config wil, maar het zelf configgen en compileren van je kernel is niet zo moeilijk/tijdrovend meer als je zou denken.

[Verwijderd]

https://www.gentoo.org/ , http://www.funtoo.org/Welcome
of het iets minder populaire/long term beheerbare http://www.linuxfromscratch.org/

Je hebt in Gentoo wel het "genkernel" script als je een meer live-cd achtige config wil, maar het zelf configgen en compileren van je kernel is niet zo moeilijk/tijdrovend meer als je zou denken.

Dat weet ik ook, dat heb ik heel vaak gedaan. Maar momenteel heeft het voor mij geen voordeel meer.
Ook omdat we geen i386/i486 etc meer hebben, daar was het verschil wel groot, c.q. nu x86_64 gebruikt wordt.

[Countess]

distro kernel's bevatten zeer zeker niet alles wat mogelijk is in de kernel. veruit de meeste dingen worden als module ingeladen, en alleen als je ze nodig hebt.

[goarilla]

Mja ... een beetje nuancering:
Slackware64 14.2 (2016)
4.2M /boot/vmlinuz-generic-4.4.29
7.3M /boot/vmlinuz-huge-4.4.29

En het is de bedoeling om de generic te gebruiken met een initrd.

[Evyd13]

Betekent dit dat mijn r9 270je eindelijk prima gaat werken op Linux? Zou hartstikke mooi zijn namelijk

[Pietervs]

Mijn r9 290 draait probleemloos op Linux. Nu heb ik wel de driver van AMD gedownload, misschien dat dat het verschil maakt?

[Evyd13]

Een combinatie van een te oude kernel en een te nieuwe grafische kaart denk ik dan

[HollowGamer]

Die werkt prima met de open-source radeon drivers (als het goed is ingebakken in de kernel door je distro).

Amdgpu support is er nu met Linux 4.9, maar volgensmij ontbreken hier nog zaken als dynamisch switchen (o.a. energie beheer), en is de prestatie nog niet echt top.

Zou op dit moment gewoon de opensource driver gebruiken en in het volgend jaar de amdgpu driver. Catalyst blijft een hel met Xorg en het ondersteunen van de nieuwste kernel.

[Reactie gewijzigd door HollowGamer op 24 juli 2024 04:13]

[ari3]

Betekent de nieuwe amdgpu driver ook dat HDMI audio op een HD4290 weer gaat werken? Sinds Ubuntu 16.04 is HDMI audio stuk terwijl het prima werkte op 14.04...

Ik zie veel forum posts van mensen die HDMI audio niet (meer) werkend krijgen met AMD GPUs in Ubuntu 16.04, terwijl het tegenwoordig een must is om dit ondersteund te hebben. Het is echt bizar dat het nog steeds niet is opgelost.

[Just3]

AMDGPU is de driver voor AMD's Graphics Core Next (GCN) GPU's (momenteel nog experimenteel voor GCN 1.0 en 1.1), i.e. de HD7000 series en nieuwer. Is die HD4290 trouwens een IGPU?

[ari3]

Ja, de HD4290 is een IGPU.

[Verwijderd]

Ik verbaas me er toch elke keer weer over dat al die support in de kernel moet zitten. Is er in Linux-land geen discussie meer over het monolithische karakter van de kernel? Ik ben geen expert, verre van zelfs dus pin me er niet op vast, maar is bijvoorbeeld de Windows-kernel dan niet veel flexibeler met zijn compleet losse drivers? Het lijkt mij dat de broncode van de Linux kernel ook groter en groter wordt. Dat maakt de keuzes bij compilatie wellicht niet overzichtelijker. 10 jaar geleden heb ik een poosje met Gentoo gespeeld, gewoon om wat over Linux te leren en destijds was een kernel compileren al flink veel keuzes maken. Vandaag moet dat een nog veel langere lijst met opties zijn. Iemand die dit toe kan lichten?

[Verwijderd]

De kernel bestaat uit een vast gedeelte en losse modules. Een Linux distributie maakt een keuze om sommige ondersteuning in de kernel te compilen en de rest als modules aan te bieden. Zo werkt alles dat gegarandeerd meekomt met de distributie altijd, en blijven er opties voor mensen die iets specifieks nodig hebben.

Wat dat betreft is een "driver" vaak niets anders dan een optionele kernel module. Als je die niet laadt, kun je de hardware niet gebruiken. De rest blijft gewoon werken.

Gentoo is niet representatief voor een Linux distributie. Denk liever aan Debian, Ubuntu, Red Hat, etc.
Verreweg de meeste Linux gebruikers hoeven zich niet druk te maken om de kernel of configuratieopties.

[Verwijderd]

Mijn vraag is eigenlijk wat het voordeel is om maar alles in de kernel te stoppen als je standaard met modules kunt werken. En de distro lijkt me niet zo relevant. De vraag is ook of de standaard 'gebruiker' wel een desktop voor zijn neus heeft. Linux draait vooral op servers, routers e.d. Het lijkt mij dat je daarop een zo efficiënt mogelijke kernel wilt draaien.

[ultimasnake]

Nu ben ik absoluut geen Linux kenner maar gebruik al tijden een Raspberry Zero voor meerdere doeleinden, wat is er dan nu toegevoegd aan de kernel? Better support? Native support (iaw compileerden distro's al spullen mee voor de Zero die niet standaard waren)... Gaat mijn Zero nu beter presteren? Leg het me ajb uit Linux fanaten!

[Reactie gewijzigd door ultimasnake op 24 juli 2024 04:13]

[jvnknvlgl]

Waarschijnlijk draait je Zero op dit moment op een kernel die is uitgegeven door de Raspberry Pi Foundation. Het verschil is dat die code nu opgenomen is in de mainline-kernel, dus je zou geen aangepaste kernel meer nodig hebben. Dit is vooral handig voor distro's, die kunnen zo dus gewoon hun standaardkernel meeleveren.

[NitSuA]

Ik heb niet zoveel verstand van kernels en linux en dergelijke, maar als ik het artikel zo lees ben ik toch benieuwd waarom al deze functionaliteit in het kernel is opgenomen. Zou het niet wenselijker zijn om dit buiten het kernel te houden? een soort mini-kernel approach ofzo?

[Fruit]

een soort mini-kernel approach ofzo?

Je bent niet de eerste met dat idee.

https://groups.google.com...comp.os.minix/wlhw16QWltI

[OrangeTux]

Dit is volgens mijn ook een LTS release.

[hsb85]

hoe krijg ik nu alleen deze kernel op mijn nexus 5? of gaat het om het beheren van een Nexus 5 vanaf een linux pc?

[CAPSLOCK2000]

Wachten tot LG het voor je doet, of zelf een nieuw image bouwen.

Of het zin heeft is vraag twee. Waarschijnlijk heeft je telefoon deze drivers al aan boord en is het nieuws dat deze drivers nu ook zijn opgenomen in de algemene kernel (en niet alleen de tak van LG). Dat is vooral handig voor nieuwe telefoons die gebruik maken van dezelfde hardware, die kunnen die drivers dan ook gebruiken.

[jvnknvlgl]

Het gaat waarschijnlijk om bepaalde ondersteuning voor de ARM-CPU van de Nexus 5, alhoewel je nu niet zomaar de kernel kan compileren om op je Nexus 5 te draaien. Daar mis je nog onder andere de Adreno-drivers voor.

[Reactie gewijzigd door jvnknvlgl op 24 juli 2024 04:13]