Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 61 reacties
Submitter: aardvark

Linus Torvalds heeft lts-versie 4.1 van de Linux-kernel vrijgegeven. De nieuwe kernel bevat veel verbeteringen en nieuwe opties. Het ext4-bestandssysteem kan nu zelf gegevens versleutelen en er is een driver voor nv-dimms toegevoegd, zodat deze als opslagmedium gebruikt kunnen worden.

Een andere opvallende toevoeging is de mogelijkheid de hardwarematige versnelling van verschillende Intel-videokaarten in virtuele machines te benutten, schrijft Heise. Het doel is deze ondersteuning in de toekomst voor alle gpu's mogelijk te maken. Nvidia's Maxwell-gpu, waaronder de Geforce GTX 750, krijgt in 4.1 3d-versnelling met de Nouveau-drivers. Voor de opensource AMD-drivers is Radeon DisplayPort MST-ondersteuning toegevoegd, waardoor beeldschermen met een resolutie hoger dan 4k of bepaalde docking-stations beter ondersteund worden.

In samenwerking met Intel is ook het nieuwe Skylake-platform aangepakt. Volgens de planning komt dit na de zomer uit. Het bevat onder andere out-of-the-box ondersteuning voor de nieuwe cpu's. Ook zijn er verbeteringen doorgevoerd voor gebruikers van de Google Pixel 2, waardoor de touchpad en het touchscreen goed werken, evenals de leds aan de buitenzijde van het scherm. Gebruikers van recente Dell-laptops kunnen de toetsenbordverlichting bedienen. Gamers die hun Xbox One-controller gebruiken, kunnen genieten van force feedback en trilmodus.

De langetermijnondersteuning van de kernel moet voor ten minste twee jaar gewaarborgd zijn. In totaal voerden de bijna 1500 ontwikkelaars ongeveer 11.660 veranderingen door. De kernel is daarmee gegroeid met meer dan 200.000 regels code. De nieuwe kernel kan op kernel.org worden gedownload of via Linus' GitHub.

Moderatie-faq Wijzig weergave

Reacties (61)

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 :P )

[edit]
Dank allen voor de uitleg, I get it now :)

[Reactie gewijzigd door ultimasnake op 22 juni 2015 15:23]

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
Waarschuwing: lang verhaal :P
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 :P) 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.

edit { 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

[Reactie gewijzigd door deadinspace op 22 juni 2015 20:20]

Mensen als jij maken voor mij Tweakers. Dank je, heb ontzettend veel geleerd van je post!
Darwin is in feite geen microkernel zoals QNX. Vrijwel alle driver zaken worden binnen kernel_task geladen. Het lijkt er op dat ze de onderliggende mach microkernel enkel gebruiken als een soort 'vmware' om kernel problemen te kunnen debuggen van buiten de kernel. Dus als kernel_task crasht dat je dan in principe nog iets lagers gelegen hebt dat nog steeds draait. Waar je dan met wat goocheltrucs als kernel guru bij Apple het systeem mee kan inspecteren. Niet iets waar jij en ik voordeel aan hebben.

QNX is veel meer zoals Minix 3, de opvolger van het genoemde Minix in het 'Torvalds debat'. Waarbij drivers in principe net als programma's kunnen crashen en worden herladen zonder dat alles perse in de soep loopt. Als je dat goed op orde hebt zou je zo een veel betrouwbaarder systeem kunnen maken. Enkel zeer korte onderbrekingen als er iets mis gaat.

Een zijstraat: Erlang, en het Ruby-achtige Elixir wat daar op gebouwd is, heeft een zelfde soort 'als een onderdeel crasht, dan lossen we het op' filosofie, maar dan op programmeertaal niveau. Interessant idee, naar mijn mening. Komt natuurlijk altijd met een prijs, dat je wat tijd en moeite aan het bewakings- en herstel-systeem moet besteden.
Ik heb afgelopen week een presentatie zitten kijken van Tanenbaum zelf tijdens BSDCan, over zijn Minix. Linkje: https://www.youtube.com/watch?v=0pebP891V0c

Misschien is het soms wat te technish, maar ik kan zeker aanraden om het eens te kijken :)
+2 maar het is net te veel off-topic... ok +1
Linux is een kernel volgens een heel ander model dan bijvoorbeeld de Windows-kernel. Linux is in aanleg een monolitische kernel (hoewel er wel met modules gewerkt wordt, dus helemaal monolitisch is hij niet) wat zoveel betekend dat alle drivers in de kernel ingebouwd zijn.

Tegenover de monolitische kernel staan de microkernel, die zoals de naam al zegt zo min mogelijk taken op zich neemt. De Windows NT kernel (alles van XP en daarna) is een hybride kernel.

TL;DR: Windows heeft losse drivers, Linux heeft ze meestal ingebouwd, dat is een ontwerpbeslissing/paradigma die men al jaren geleden genomen heeft.
Sinds windows NT.. Waarbij MS alleen Windows NT beschikbaar stelde aan zakelijk gebruikers.. Pas sinds XP is de kernel ook voor particulieren.

WIndows NT begon bij versie 3.1 1992 of 93 ..
in 2002 kwam XP die het ook naar de huizen bracht voor heen was NT echt alleen zakelijk bedoeld.. om servers en workstations aan te sturen.. Pas bij NT4.0 werd het echt populair onder beheerders om dit voor te schotelen voor de eindgebruikers..

in 2000 gingen ook de kleinere bedrijven langzaam over op de NT kernel.. pas in 2002 XP tijdperk.. Was 90% van de werkstations wel vervangen voor een NT versie..
Wat dacht je van nooit meer drivers installeren? ;) Verder heeft het als voordeel dat drivers functionaliteit kunnen delen, waardoor je minder bugs en minder code-duplicatie krijgt. En er is mooi een centrale repository waar alle code bijgehouden wordt. Aangezien de kernel modulair is opgebouwd, gebruik je alleen de code/modules die je nodig hebt ;)
Wat dacht je van nooit meer drivers installeren?
(...)
Dat is natuurlijk maar een discutabel voordeel als het betekent dat je voor een driver update je je hele OS moet upgraden.

Ik moet bekennen dat ik niet weet waarom je voor kernel modules of drivers zou moeten kiezen, maar als het dan toch kernel modules moeten worden, vind ik dynamisch laadbare kernel modules zoals in Solaris wel een stuk eleganter en flexibeler.
Dat is natuurlijk maar een discutabel voordeel als het betekent dat je voor een driver update je je hele OS moet upgraden.
Je hoeft niet het hele OS te updaten, de kernel kan los worden bijgewerkt. Veel distributies (maar niet allemaal) doen dat ook.
Ik moet bekennen dat ik niet weet waarom je voor kernel modules of drivers zou moeten kiezen, maar als het dan toch kernel modules moeten worden, vind ik dynamisch laadbare kernel modules zoals in Solaris wel een stuk eleganter en flexibeler.
De Linux kernel modules zijn dynamisch laadbaar (en ook ontlaadbaar ;). Voor oudere kernel versies was dat in praktijk alleen niet altijd even handig. Je wil niet de driver van je harde schijf verwijderen terwijl je OS op die schijf staat. Sinds 4.0 is er echter een mechanisme om draaiende drivers in-place te upgraden.
Je kan dus zonder reboot je drivers updaten.
De Linux kernel modules zijn dynamisch laadbaar (en ook ontlaadbaar ;). Voor oudere kernel versies was dat in praktijk alleen niet altijd even handig. Je wil niet de driver van je harde schijf verwijderen terwijl je OS op die schijf staat.
Een driver unloaden die in gebruik is is volgensmij nooit mogelijk geweest in de 15 jaar dat ik Linux gebruik ;)
# rmmod ahci
rmmod: ERROR: Module ahci is in use
# rmmod ext4
rmmod: ERROR: Module ext4 is in use
Ja, dat bedoel ik, het systeem laat het niet toe om draaiende drivers te verwijderen, dat is te onhandig. Met randapparatuur (geluidskaart, graca, netwerkkaart) is het wel te doen. Als je dat ext4 filesystem kan umounten mag je ook de driver verwijderen maar als dat je root-filesystem is lukt dat natuurlijk niet. (ok, echte mannen gebruiken pivot_root en dan kan het wel ;)
@Capslock & Blokker:

Als kernel modules tegenwoordig wel dynamisch laadbaar zijn,is dan die hele kernel module versus driver niet een non-discussie?

En is Umbrah's stelling boven dat Linux een monolitische kernel is achterhaald?
Monolitisch = kernel als een proces
Micro kernel = kernel is minimale functionaliteit (memory management, scheduling, message passing) en alle andere functies in separate processen.

De linux kernel is inmiddels ook niet meer monolitisch want er bestaan kernel threads (ook een soort van processen). het is dus tegenwoordig ook een soort van hybride kernel.
Windows NT 3.51 was een Micro-kernel design, vanaf NT 4.0 zijn een hoop driver functies in de kernel getrokken omdat context switches voor driver aansturing te duur was. met name voor de Video driver.

Modulair zijn tegenwoordig vrijwel alle kernels, het is niet noodzakelijk om een nieuwe kernel te linken bij aanpassingen aan de hardware configuratie. Alle drivers en andere functies kunnen als kernel module geladen worden.
Bij de linux kernel is aangegeven dat als je driver door kernel.org (i.c. Linus) geaccepteerd wordt, dat dan ook aanpassingen in de interne API's voord e betreffende module worden meegenomen.
Zo zijn voor de nieuwe 4.0 en 4.1 kernel nog geen geschikte ATI-drivers beschikbaar omdat die niet bij kernel.org beschikbaar zijn. AMD doet liever zelf het onderhoud op de veranderende API's.... dan dat de sources voor de drivers beschikbaar worden gesteld.
Tweaknico legt hierboven al prima uit dat een monolitische kernel los staat van het gebruik van modulaire drivers. Een monolitischer kernel kan gewoon losse, modulaire drivers gebruiken. (In theorie zou een micro-kernel ook zonder modulaire drivers gebouwd kunnen worden maar dat is een beetje onzinnig en nutteloos).

De meests OS-wetenschappers vinden het monolitische ontwerp verouderd maar alle OS'en die wij gebruiken volgen dat ontwerp nog in meer of mindere mate.

Het is ongeveer zo achterhaald als benzine. Er is brede overeenstemming dat de olie ooit op raakt en dat elektromotoren eigenlijk veel mooier zijn maar praktisch gezien rijden de meeste auto's nog steeds op benzine.
Nu nog even een mogelijkheid om heel de kernel een in-place upgrade te geven en rebooting is een spook uit het verleden ;)
Ik was misschien iets te kort door de bocht. Dat mechanisme kan meer dan alleen drivers updaten maar ik weet niet waar de grenzen precies liggen. Voor kleine updates zijn in principe geen reboots meer nodig maar sommige stukken van de kernel zijn nog niet geschikt gemaakt voor dat nieuwe systeem.
Ik was misschien iets te kort door de bocht. Dat mechanisme kan meer dan alleen drivers updaten maar ik weet niet waar de grenzen precies liggen.
Ik las her en der dat je nooit meer hoeft te rebooten voor een kernel-update. Dit heeft vooral voor servers enorme voordelen; nooit meer downtime voor kernel-updates!

Maar misschien kan iemand met meer kernel-kennis dan ik hier wat licht op werpen? Ik ben namelijk ook wel benieuwd naar de details!
Helemaal nooit meer is ook niet waar. Bij bepaalde grote ingrepen zal een reboot nodig blijven. Een hoop kleine updates kunnen nu wel al zonder reboot worden toegepast en in de komende kernelversies zal die functionaliteit zich steeds verder verspreiden en verbeteren.

Je kan je afvragen of het ook verstandig is om nooit meer te rebooten. Er kan altijd een storing optreden zoals stroomuitval waardoor je wel opnieuw moet booten. Het is vervelend als je er pas op dat moment achter komt dat de bootprocedure stuk is. Dan kun je beter af en toe onder gecontroleerde omstandigheden het systeem rebooten.

Het grootste voordeel vind ik zelf dus dat je dringende patches dus onmiddelijk kan toepassen zonder dat daar automatisch een reboot bij hoort. Zo'n reboot is nog steeds nuttig maar dan op een moment dat je zelf hebt gekozen.
Waar men dus ook aanhaald dat er nog obstakels overwonnen moeten worden. Daarnaast lijkt het mij ook alleen maar te gaan om de functionaliteit die we nu zien voor het vervangen van modules.
Je kan er in linux ook voor kiezen om je drivers modulair in te laden als kernel modules. Die kan je dan ook extern updaten zonder dat heel de kernel moet bijgewerkt worden.
Verder heeft het als voordeel dat drivers functionaliteit kunnen delen, waardoor je minder bugs en minder code-duplicatie krijgt
Ik zou veiligheid voorrang verlenen. Dus gedeelde code alleen uit libraries. Natuurlijk horen drivers niet in een kernel en filesystemen al helemaal niet. Maar eigenlijk is de linux kernel ook helemaal geen kernel, het meer een core OS. Dat de linux kernel niet netjes volgens de boekjes in elkaar zit is jammer maar in de praktijk geen probleem. Ook TCP/IP is niet netjes volgens het OSI model gemaakt maar werkt ook prima.
Ik zou veiligheid voorrang verlenen. Dus gedeelde code alleen uit libraries. Natuurlijk horen drivers niet in een kernel en filesystemen al helemaal niet. Maar eigenlijk is de linux kernel ook helemaal geen kernel, het meer een core OS. Dat de linux kernel niet netjes volgens de boekjes in elkaar zit is jammer maar in de praktijk geen probleem.
Traditioneel horen drivers en filesystems wel degelijk tot de kern-taken van een kernel. Er is een stroming die micro-kernels nastreeft waarbij dit soort taken in userspace draaien. Conceptueel is dat mooi maar het heeft wel een force impact op de performance en voegt extra complexiteit toe.
Geen van de grote OS'en (Windows, Linux, MacOS) heeft een echte microkernel. Ze hebben er allemaal aspecten van overgenomen maar in essentie zijn het toch meer monolitische kernels. De Linux-kernel is monolitisch begonnen en heeft steeds meer kunstjes van microkernels over genomen. De Windows is juist de omgekeerde weg gegaan. Zo zaten grafische drivers in NT niet in de kernel maar tegenwoordig (sinds XP IIRC) weer wel.
Ik snap je probleem in denken wel, waarom AMD drivers in mijn kernel als ik exclusief Intel draai? Ik kan immers nog steeds niet m'n HDD swappen van machine A naar machine B en verwachten dat m'n Linux nog gewoon boot!?

Ware het niet dat het uiteindelijk allemaal niet zoveel invloed heeft op de performance. Ja, Linux installaties kunnen iets kleiner als je niet al die ongebruikte drivers meeneemt, maar in voor werkgeheugen gebruik maakt het weer weinig uit. Daarnaast wordt er heel veel hergebruikt, iets waar Windows weer een voorbeeld aan zou kunnen nemen.

Maar één van de dingen die je kunt doen als je het allemaal wilt streamlinen is je eigen kernel compilen, zodat je enkel kunt toevoegen wat je wilt gebruiken.
Ik kan immers nog steeds niet m'n HDD swappen van machine A naar machine B en verwachten dat m'n Linux nog gewoon boot!?
Waarom niet? Dat werkt meestal prima hoor. :)

Wat geheugengebruik betreft. In de meeste distributies zijn de daadwerkelijke "drivers" voor allerlei specifieke hardware geen vast onderdeel van de kernel, maar als modules gecompileerd. Deze worden pas ingeladen als de hardware waarvoor een betreffende module geschikt is aanwezig is. In mijn Intel laptop met Intel GPU wordt bijvoorbeeld geen radeon module ingeladen omdat deze niet nodig is. En ook enkel de ath9k module voor mijn Atheros WiFi chip, terwijl de modules voor o.a. Intel, Broadcom en RAlink chips niet ingeladen worden.

[Reactie gewijzigd door Ultraman op 22 juni 2015 14:59]

Tja... Het zou moeten werken. Maar ik heb het nog nooit buiten live-usb-OS achtige oplossingen werkend ervaren...
De laatste jaren ben ik vooral in de Fedora / Redhat / CentOS omgeving gebleven. Maar voorheen met Mandriva / Ubuntu is het ook nooit gelukt...

Ik heb b.v. momenteel een RedHat en een Fedora 22 installatie op 128 en 64GB USB3.0 stick staan. Als ik die tussen (Identieke!!!) machines wissel, (zelfde Xeon, moederbord, Ram en GPU!) verteld dracut mij dat het mountpoint toch echt niet hetzelfde is en de hardware niet gevonden kan worden. Ik heb voor Fedora wel een kernel die er soort van tegen kan, maar iedere swap moet er vanalles herbouwd worden.

SSDtje met CentOS van een Intel i3 Nvidida 520MX naar een Intel i5 Nvidia 520MX? Nope, bekijk het maar, zelfs met dezelfde generatie Sata controller van Intel is de map niet overeenkomstig genoeg.

Ik gebreep wel dat kernel 4.03 ertegen kon als je AMD / Nvidia videokaarten tegelijk draait. X vind het prima als ik m'n Nvidia uitgooi en naar Intel HD wissel, je zou bijwijze van spreken kunnen hotswappen. Maar het gaat op de Sata mountpoint fout in veel gevallen.
Dat zou heel goed te maken kunnen hebben met EFI, waarbij unieke nummers aan Filesystemen worden toegekend. Als de profielen van beide sticksjes op beide machines bekend zijn dan kunnen ze op beide gebruikt worden.
Dit is meer een EFI issue dan een Linux issue.
(En BIOS is op dergelijke machines een emulatie de door EFI gestart wordt).
Ik heb zelf al meermaals een HDD uit 1 systeem in een totaal ander systeem gestoken, systeem opgestart en Linux boot gewoon, detecteerd de modules die het moet laden en gaat rustig verder. Ik deed dit 10 jaar terug al, en enkele weken terug ook toen ik van mijn oude AMD naar mijn nieuwe Intel PC ging waarbij dus ook een swap van BIOS naar UEFI zat..

Waar je vandaag vooral voor moet zorgen is dat je overal de UUID van je filesystem gebruikt en niet langer werkt met verwijzingen naar het device op zich. De UUID is weggeschreven in de partitietabel en bootloader en kernels kunnen daar vandaag perfect mee overweg. In je fstab staat dan ook niet langer als device je /dev/sda1 maar wel UUID=85d1daa9-8c2b-4bd0-a5ff-5b67e297a708

Het probleem met grafische kaarten is dat er wel vaak specifieke drivers voor geïnstalleerd worden die niet altijd op het systeem staan. Maar dan is het gewoon een kwestie om vanop de command line die even te installeren en in no time ben je weer up and running met je desktop.
Ironisch genoeg zou dat waarschijnlijk dus wel werken (HD swap)
Hooguit dat X niet op komt tot je de correcte graka drivers erop hebt gezet.

Ik heb eens de graka gewisseld tussen AMD en NVidia. Buiten dat de resolutie zonder de gesloten driver ruk was werkte het prima zonder foutmelding of wat dan ook.

[Reactie gewijzigd door hackerhater op 22 juni 2015 15:10]

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.?
Met de Linux kernel worden ook drivers meegeleverd, waar de betreffende functionaliteit uit jouw voorbeeld in zit. ;)

In Linux zijn de kernel en drivers veel meer met elkaar verweven al vergelijk je het met Windows. Zo moet (over het algemeen) bij het installeren van een nieuwe kernel drivers opnieuw gecompileerd worden. Bij Windows werkt dit iets anders (je kan onder 7 en hoger nog steeds Vista drivers gebruiken in bepaalde gevallen, bijvoorbeeld).

Als Linux open-source drivers volwassen zijn, worden ze vaak meegenomen in de kernel en onderhouden wanneer nodig bij updates. Dit is veel makkelijker voor zowel het onderhoud (ontwikkelaars) als voor het het installeren van een nieuwe kernel (gebruikers/distributiebakkers), dat bij Linux vaak voorkomt.

[Reactie gewijzigd door The Zep Man op 22 juni 2015 11:55]

Windows Vista en Windows 7 zijn beide NT 6.x. Maar ik geloof dat driver compatibiliteit onder Windows toch verder backwards compatible is. Mogelijk dat drivers geschreven voor NT 3.1 nog onder Windows 7 (of nieuwer) kunnen draaien. (voor 32 bits x86 versies)
Nee, Microsoft heeft specifieke driver models al meermaals op de schop genomen. Voor een deel klopt het dat er nog backwards compatibility bestaat, maar voor onder meer grafische kaarten zit je vandaag toch echt vast aan een nieuw driver model.

Dat was ook direct 1 van de pijnpunten bij de release van zowel XP als Vista. Vele drivers waren ineens niet meer compatibel waardoor oudere hardware niet langer ondersteund werd.

Zelfs in het 9x tijdperk had je dit al. De onstabiliteit die vele mensen hebben ervaren met Me werd maar al te vaak veroorzaakt door slechte drivers omdat er aanpassingen waren gemaakt in het drivermodel.
Iemand die hier al iets meer over weet?
"...driver voor nv-dimms toegevoegd, zodat ssd's als ram ingezet kunnen worden"


Met de nieuwe standaard om snel access te krijgen tot een pci-e ssd is dit misschien wel heel erg leuk?

Tot nog toe is een ssd gebruiken als Swap leuk, maar om het echt als werkgeheugen te gebruiken is dacht ik echt te traag. Kan dit een stap in de goede richting zijn?
* ssd zal altijd trager zijn dan echt ram, maar misschien word het werkbaar. Ik doel hier op servers welke ~1TB ram hebben en waarvoor een uitbreiding maar 2TB ram ineens te betalen is.
Verplicht leesvoer hieromtrent:

Overzicht van LightNVM (volgens mij doelt het T.net artikel hierop):
https://lwn.net/Articles/641247/

Persistent memory: (dit is waar het in de toekomst echt om zal draaien)
https://lwn.net/Articles/640113/
https://lwn.net/Articles/644079/

Er is een dummy driver toegevoegd die nonvolatile memory als een block device exposed. Deze is vooral bedoeld om wat ervaring op te doen en om iets te hebben tegen dat zo'n hardware effectief komt.

Er bestaan vandaag al battery-backed DIMMs waarmee je gewoon de performance hebt van normaal geheugen. Wat de toekomst brengt is koffiedik kijken. De vendors die ermee bezig zijn houden de lippen stijf en er sijpelt slechts mondjesmaat informatie naar buiten.
Er zijn geruchten dat NVM slechts een beperkt aantal write-cycles heeft, dat het "bijna even snel" is als gewoon RAM en meer van dat soort onbetrouwbare uitspraken. Alles zal uiteindelijk afhangen van welke technologie je bekijkt (MRAM, ReRAM, phase-change memory, etc.)
Intel heeft trouwens een tijd terug wat instructies toegevoegd om betrouwbaar met NVM te kunnen werken (o.a. pcommit end clflushext).

[Reactie gewijzigd door H!GHGuY op 22 juni 2015 12:57]

Misschien wordt het je Diets ;) met onderstaande citaat uit het uitgebreide artikel op de site van Heise. Naar mijn idee gaat het dus niet om ssd, maar om het aanspreken van nv-dimm als opslag.
Schneller als SSDs

Mit "PMEM" enthält der Kernel jetzt einen simplen Treiber, um NV-DIMMs wie Datenträger anzusprechen. Bei den Ende März vom zuständigen Gremium spezifizierten NV-DIMMs handelt es sich um Arbeitsspeichermodule, die wie RAM angesprochen werden, den Speicherinhalt aber auch ohne Stromversorgung behalten; dadurch arbeiten sie nochmals um einiges schneller als die derzeit schnellsten SSDs.
Je hebt gelijk. Aangepast, ga kijken of ik dat nog wat uitgebreider uit kan leggen.
Voor de geïnteresseerden, de broncode staat op GitHub:

https://github.com/torvalds/linux
Het is overigens wel interessant om te vermelden dat GitHub puur als mirror word gebruikt.
Torvalds zelf werkt via http://git.kernel.org/

Zie: https://github.com/torval...l/17#issuecomment-5654674
Voor degenen met Ubuntu:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1-unstable/

- Download headers-generic_[amd64/i386].deb, headers_[amd64/i386]_all.deb, en linux-image-generic-[amd64/i386].deb naar een lege map
- Op de commandline: cd legemap; sudo dpkg -i *.deb

Mocht er onverhoopts iets niet meer goed werken, selecteer dan tijdens het opstarten in GRUB de vorige kernel.

P.s. als je de laatste features allemaal wilt kunnen gebruiken, voeg de volgende ppa toe en update je systeem (let op, wel allemaal unstable):
https://launchpad.net/~ka...ubuntu/experimental-stuff

[Reactie gewijzigd door twicejr op 22 juni 2015 11:58]

Thanks! Erg handig!

Maar aangezien het nog de unstable is, wacht ik er even mee.
ik heb hem noodgedwongen (Wegens een kernel bug met me CPU) moeten draaien, en ik kan je vertellen dat hij behoorlijk stabiel is (draai hem een maand of 2 nu zonder issues) op mijn servertje, die een Dev webserver is - 24/7 een teamspeak en minecraft server draaid, en soms wat downloading doet.

uname -r
4.1.0-999-generic

cat /etc/issue
Ubuntu 14.10

(oh en die kernel bug in de 3 kernel is trouwens met de Intel(R) Celeron(R) CPU J1900 CPU)

zal hem dus maar eens updaten binnekort naar de stable versie.
Is die bug ook teug te vinden in andere cpu's? en wat is die bug dan?

Maar wel positief om te horen dat hij stabieler is dan het mogelijk lijkt.
Lijkt specifiek voor dat type te zijn, en in de 3 tak, de latest stable (.19) was het in iedergeval nog niet opgelost. en in de .13 zat de bug nog niet dus de .16 en .19 variaties waren bugged. er was wel een patch voor, maar dan moest je eigen kernels gaan compilen en allerlei ongein uithalen om het werkend te krijgen.

wat bug reports van verschillende distros:

https://redmine.pfsense.org/issues/3678
http://bugs.centos.org/view.php?id=7405
https://bugs.freenas.org/issues/4996
https://bugs.freedesktop.org/show_bug.cgi?id=88012
enz.

verschillende OSen dus (maar ja dat heb je met kernels al snel). sommige mensen hadden succes met Cx status naar C1 of uit te zetten in het bios, en alle power saving states uit te zetten, het lijkt er op als de CPU wil terug schakelen in stroom verbruik er iets mis gaat waardoor de kernel panict (zet iets te veel uit ofzo ik weet het niet helemaal zeker) sinds 4.1 er op staat 100% uptime, en geen enkele kernel panic.
De kernel is daarmee uitgegroeid tot meer dan 200.000 regels code.
De kernel is meer dan 200.000 regels groter geworden, het totale aantal regels is veel hoger.
Dat leek mij ook wel, aangezien het aantal regels van de 1.0.0 kernel (dat uit 1994 stamt) uit 176,250 regels bestaat.

In 2011 bestond het aantal regels uit 15 miljoen regels en gek genoeg is Microsoft (toen der tijd) 1 van de van de grootste supporter

[Reactie gewijzigd door vali op 22 juni 2015 12:32]

Waarom is dat gek?
Ben je de bron vergeten?

En ook, veel mensen die naar Microsoft komen om geld te verdienen waren mogelijk al supporter in hun vrije tijd, maar ja, er moet ook brood op de plank en als werkgever is Microsoft absoluut niet een verkeerde organisatie om voor te mogen werken.
Als je op 15 miljoen regels had getikt had je de bron gevonden :). Ik vind het totaal niet gek (sterker nog, Microsoft voegt veel regels toe zodat het perfect draait op hun Azure/ Hyper-v omgeving), maar die hard Linux fanaten kunnen dit eventueel wel gek vinden. Aangezien die vaak niks van Microsoft te maken willen hebben.
new addition to the list of top contributors this year was Microsoft. The Redmond giant was the 17th most prolific corporate contributor to the Linux kernel in 2011. The company first began contributing code to Linux in 2009 when it submitted patches to improve the performance of running virtualized Linux guest instances on Windows servers

[Reactie gewijzigd door vali op 22 juni 2015 12:26]

De Linux gemeenschap is over het algemeen zeer open en minder closed minded dan bijvoorbeeld de Apple omgeving. Dat MS gedurende enkele jaren grote inspanningen heeft geleverd om Linux goed te krijgen op hun virtualisatie platform is heel mooi van hen en niet onbelangrijk (indien ze willen blijven concureren met de rest). De mindset binnen MS dat Linux een onbelangrijk iets is, die is al lang verleden tijd. Hoe langer hoe meer begint MS ook naar dit platform te kijken om andere technologie op uit te rollen. Zo hebben ze recent nog de basis van .Net geschikt gemaakt voor het Linux platform.
Dat klopt. Microsoft is flink verandert en zijn allang niet meer zo stug meer hoe ze vroeger waren. Ik ben er alleen maar blij mee, want ik kon hierdoor zeer gemakkelijk een Linux bak virtueel installeren op mijn hyper-v server :)
Tjsa, die moet ook weten hoe 'het' moet. ;)
Waar haal je dat?

Microsoft komt in de 4.1 statistics zelfs niet eens naar voor. Microsoft heeft een klein poosje wel voorgekomen in die statistics toen ze hun Hyper-V drivers hebben toegevoegd in de kernel.

edit: je hebt zonet je reactie aangepast, zie ik. Maakt deze reactie wat overbodig.

[Reactie gewijzigd door H!GHGuY op 22 juni 2015 12:43]

Ik had het ook over kernel 3.0 dat alweer uit 2011 stamde. Dat stond ook in mijn verhaal. Wat ze toen hadden gedaan kon je in de link terug vinden of in het rapport.

Stukje van een interview van Greg Kroah-Hartman:
Hartman was instrumental in bringing Microsoft's Hyper-V into the Linux fold, a project started in 2009 after it was revealed Microsoft violated the GPL free software license by using open source components in a Hyper-V driver.

Today, work with Microsoft is going well, Kroah-Hartman said. "The code has been in the Linux kernel for a few years now, and has recently moved out of the staging area of the kernel, into the main portion of the different kernel subsystems for the specific drivers," he said.

When asked if he's happy with Microsoft's contributions to Linux, he said "I am very happy with their contributions. The work that they have done on their drivers is amazing. The original driver submission was over 20 thousand lines long. Two new drivers have been added to the codebase, and lots of cleanup, making the final line count around 7 thousand lines. This shrinkage shows that working with the kernel community enables companies to reduce the size of their code, making things faster, easier to maintain, and less buggy."

[Reactie gewijzigd door vali op 22 juni 2015 12:41]

"gegroeid met meer dan 200.000 regels code" staat in de tekst. Dat betekent toch echt: meer dan 200.000 regels erbij.
Dan is het toch duidelijk aangepast, je ziet de quote toch die Onno heeft toegevoegd, die is duidelijk niet gelijk aan wat er nu in het artikel staat...
Zie ook waar dit soort foutjes gemeld mogen worden, zodat niet hele topics ineens over (kleine) foutjes gaan: Geachte Redactie
:)
Heeft iemand meer informatie welke dockings er nu ondersteund worden? Tot nu toe was dit nog steeds een lastig verhaal wanneer je een docking met display link hebt.
lts-versie 4.1.De nieuwe kernel bevat veel verbeteringen en nieuwe opties. Het ext4-bestandssysteem kan nu zelf gegevens versleutelen....
--------
Voor de opensource AMD-drivers is Radeon DisplayPort MST-ondersteuning toegevoegd, waardoor beeldschermen met een resolutie hoger dan 4k of bepaalde docking-stations beter ondersteund worden.
------
De langetermijnondersteuning van de kernel moet voor ten minste twee jaar gewaarborgd zijn.
Ik zit momenteel vast op kernel versie 3.19.0-21(Kubuntu 15.04),dus even wachten dan maar. :P

[Reactie gewijzigd door Chame_Wizard op 22 juni 2015 13:55]

Waarschijnlijk krijg je deze kernelversie niet aangeboden door Ubuntu omdat zij met de 3.19 kernelversie werken op 15.04. Ik verwacht niet dat zij dergelijke nieuwe features backporten, want meestal worden enkel fixes gebackport vziw.
Maar er is waarschijnlijk wel een recentere kernel beschikbaar uit een testing repo voor 15.10 of middels een PPA van het kernelteam. Dus als je wilt zou je daar even naar kunnen zoeken, er is zeker wat over geschreven en te vinden.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True