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 , , 34 reacties
Bron: KernelNewbies, submitter: The Jester

Linus Torvalds heeft weer een nieuwe Linux Kernel uitgebracht die bomvol zit met nieuwigheden, zoals KVM en een fault injection debugging feature. Het versienummer is aangekomen bij 2.6.20 en zoals gewoonlijk is de volledige lijst met veranderingen op Kernel.org na te lezen. Daarnaast kan je bij KernelNewbies terecht voor een overzichtelijke beschrijving van alle aangebrachte veranderingen die ze als volgt samenvatten:

Short overview:

2.6.20 makes linux join to the virtualization trends. This release adds two virtualization implementations: A full-virtualization implementation that uses Intel/AMD hardware virtualization capabilities called KVM and a paravirtualization implementation that can be used by different hypervisors (Rusty's lguest; Xen and Vmware in the future, etc),. But this release also adds initial Sony Playstation 3 support, a fault injection debugging feature, UDP-lite support, better per-process IO accounting, relative atime, support for using swap files for suspend users, relocatable x86 kernel support for kdump users, small microoptimizations in x86 (sleazy FPU, regparm, support for the Processor Data Area, optimizations for the Core 2 platform), a generic HID layer, DEEPNAP power savings for PPC970, lockless radix-tree readside, shared pagetables for hugetbl, ARM support for the AT91 and iop13xx processors, full NAT for nf_conntrack and many other things.
Moderatie-faq Wijzig weergave

Reacties (34)

Tip voor om te kijken of je cpu geschikt is voor KVM:
How can I tell if I have Intel VT or AMD-V?

With a recent enough Linux kernel, run the command:


egrep '^flags.*(vmx|svm)' /proc/cpuinfo

If something shows up, you have VT. You can also check the processor model name (in /proc/cpuinfo) in the vendor's web site.

EDIT: waarom is mijn vorige message weg-gemod? Heeft alles te maken met de nieuwe kernel.
Misschien ligt het aan mij maar ik heb de laatste tijd bij de kernel updates niet het gevoel dat er echt iets boeiends gebeurt, zoals een groote speed-up ofzo :?
KVM is toch echt wel geweldig en nieuw in deze kernel; virtuializatie a-la vmware maar dan gemakelijk (en niet zo omslachtig als Xen)
KVM is toch echt wel geweldig en nieuw in deze kernel; virtuializatie a-la vmware maar dan gemakelijk (en niet zo omslachtig als Xen)
Inderdaad, dit is een geweldige feature die zowel voor desktop als server gebruikt nuttig is. Voor server gebruik is dit zeer nuttig omdat men graag services compleet geisoleerd van elkaar draait. Voor de desktop gebruik is het zeer nuttig om bijvoorbeeld een virtuele Windows te draaien naast Linux met near-native performance.
zoals een groote speed-up ofzo
Een speed-up is alleen mogelijk als er momenteel een performance probleem is in de kernel. Is dat er?
Een speed-up is alleen mogelijk als er momenteel een performance probleem is in de kernel. Is dat er?
Mwhoah, tenzij een implementatie 'bewezen' maximaal optimaal is (wat slechts voor zeer weinig algorithmes theoretisch mogelijk is, maar dat weet je zelf ook wel natuurlijk), kan het altijd beter ;)
Nou, ik heb juist het idee dat er in deze kernel weer erg veel gebeurd is :)
Eerder toevoegen van features en bugfixing. Ook goed dat dit gebeurt (kernelnewbies.org)
Ik heb geleerd dat een goede kernel zo klein mogelijk is. Als ik lees dat er virtualisatie is toegevoegd krijg ik het gevoel dat dit niet perse nodig is.

Weet iemand of er trouwens ook meer van deze onnodige features in de kernel zitten of dat ze hebben gekozen om alleen de 2.6v zo vol mogelijk te stoppen.
Hé, je hoeft het er allemaal niet in te stoppen. Als jij geen virtualisatie in je kernel wilt dan kan dat. It's all up to you!
Nog niet zo lang geleden is er al een bericht naar buiten gegaan dat de kernel zo goed als uitontwikkeld is, toch?
de updates die nu nog komen zullen drivers zijn, bug fixes e.d. nieuwe features zullen zo goed als niet meer komen daar alles er zo goed als in zit... Dit is wat ik een tijdje terug ergens geleden gelezen heb... weet de bron niet meer.

Kan het ook mishebben :)
Heb ik ook gelezen: ik dacht dat Linus een oproep had gelanceerd om te beginnen aan een 2.8 kernel om nieuwe functies in te stoppen en in de 2.6 enkel nog bugs te squashen en nieuwe hardware toe te voegen.

Sindsdien heb ik hier niets meer van gehoord - misschien is dit idee afgeschoten geweest? Misschien is men intussen toch begonnen aan (de roadmap van) de 2.8-kernel?
Ik had gelezen dat Linus geen nieuwe kernel wilde beginnen zolang alles opgelost kon worden zonder ingrijpende wijzigingen...en het zag er niet naar uit dat dat snel zou gebeuren.

Niets mis mee, en volgens mij goed; nu kan men zich focussen op het uitblinken in hardwareondersteuning en architectuurondersteuning...onlangs nog een review gelezen van Windows Vista en Linux (MEPIS)...resultaten: Linux had veel minder problemen op de 1 jaar oude pc en Vista kon zelfs de on-board geluidskaart niet aan de praat krijgen 8-)

Linux 2.8 mag van mij een port in Erlang worden...Erlang ondersteunt hot code swapping en dat is precies wat we nodig hebben om helemaal nooit meer te moeten rebooten; ook niet bij een kernelupgrade :9~
Linux 2.8 mag van mij een port in Erlang worden...Erlang ondersteunt hot code swapping en dat is precies wat we nodig hebben om helemaal nooit meer te moeten rebooten; ook niet bij een kernelupgrade
Lijkt me moeilijk. Dan moet je eerst nog wel een Erlang runtime/virtual machine draaien. :) Gaat die dan rechtstreeks op de hardware lopen of op onder een standaard linux kernel? Vervolgens heeft je nieuwe Erlang linux kernel een feature nodig die niet in je Erlang VM zit en moet je eerst de VM upgraden en rebooten voordat je je hot code swapping kan gebruiken... :D
Lijkt me moeilijk. Dan moet je eerst nog wel een Erlang runtime/virtual machine draaien.
Je zou natuurlijk (theoretisch) een systeem kunnen bedenken waarbij bij een upgrade de kernel en/of een runtime redundant uitgevoerd is. De draaiende kernel doet eerst een upgrade voor een standby kernel, activeert die standby kernel (er draaien er dan 2!) en migreert dan langzaam alle draaiende processen naar de 2de kernel.

Dit is overigens verre van triviaal. Bij een huidige kernel upgrade is het al nodig dat je bijna alles wat los en vast zit overnieuw compileerd. Dit is met name zo omdat Linux geen binaire compatibiliteit kent. Bestaande code linkt hard naar bepaalde geheugen adressen, die natuurlijk (zonder voorzorgen) compleet anders kunnen zijn bij een kernel upgrade.
Je zou natuurlijk (theoretisch) een systeem kunnen bedenken waarbij bij een upgrade de kernel en/of een runtime redundant uitgevoerd is. De draaiende kernel doet eerst een upgrade voor een standby kernel, activeert die standby kernel (er draaien er dan 2!) en migreert dan langzaam alle draaiende processen naar de 2de kernel.
Theoretisch misschien mogelijk, maar in de praktijk zo goed als ondoenbaar vrees ik. Er zouden overal extra abstactielagen tussen allerelei componenten moeten komen om te vermijden dat code A rechtstreeks afhangt van de datastructuren van code B. Dat zou zo een impact op de performantie hebben dat het onaanvaardbaar is.
De kernel nog wat meer modulair maken en betere installatie/update tools zijn de enige realistische oplossing om het upgrade gegeven beter te maken IMHO.
Er zouden overal extra abstactielagen tussen allerelei componenten moeten komen om te vermijden dat code A rechtstreeks afhangt van de datastructuren van code
Precies, en ooit zul je toch ook eens die abstractie lagen moeten updaten, zodat je alsnog moet rebooten.

Wat je wel kunt doen, en wat wij bijvoorbeeld in het klein doen (natuurlijk absoluut niet te vergelijken met zoiets als de Linux kernel die 10.000 keer zo complex is), is voor modules wel een abstracte laag defineren maar dit niet tot in het extreme door te voeren.

We onderscheiden dan 2 upgrades: upgrades die ergens iets aan de datastructuren veranderen en upgrades die alleen via de interfaces lopen (die niet veranderde). Bij de eerste moet de app down, wordt een upgrade gedaan, en gaat ie weer up. Bij de 2de situatie kan de upgrade hot plaatsvinden op ongeveer de manier zoals ik boven schetste.
Waarom zou je per se je Erlang OTP VM moeten rebooten?
Reactie verwijderd
De rede waarom ze nog niet aan 2.7 bezig zijn.
Is omdat er geen schokkende di9ngen in de kernel hoeven.

Schokkend in de zien van. Ingrijpt in de kernel. Veel dingen zijn modular. Zodat Het maar om een klein gebied van de code gaat. Vandaar dat ze nog niet de behoefte hebben aan 2.7
Een belangrijk onderdeel van deze release is virtualization. Zou dus niet zeggen dat de kernel al uitontwikkeld is.
We zullen pas achteraf weten of de kernel is uitontwikkeld, maar naar mijn mening zijn we daar nog lang niet.
Eind 19e eeuw dacht men ook dat de wetenschap nu wel zo'n beetje klaar was, en toen kwamen Einstein en co langs...
Een vraag waar ik al een tijd mee zit, als er steeds meer dingen aan de Linux kernel worden toegevoegd, wordt hij dan niet steeds meer 'bloated'? Ik zie namelijk heel veel dingen waar ik niets mee kan: 'full-virtualization implementation', 'Sony Playstation 3 support', 'DEEPNAP power savings for PPC970'. Waar ik wel bang voor ben is dat Linux voor mij steeds trager zou worden (booten) en meer geheugen zal gaan gebruiken.

Zijn deze zorgen terecht of begrijp ik het verkeerd?
Gewoon de kernel zonder alle meuk compileren. Dat is nu het mooie van de Linux-kernel :Y)
Je kunt inderdaad de kernel zo licht compilen als je zelf wilt. Kijk maar eens naar wat diverse embedded systemen voor een extreem lichte linux kernel hebben. Dat is in essentie ook gewoon een 'standaard' Linux kernel (standaard bestaat eigenlijk niet, maar goed), met zowat alle meuk eruit.

Met alles erin is de Linux kernel voor het grootste gedeelte een grote binaire blob ja. Dat is een bewuste design beslissing, die gedaan is voor de performance. Des te meer communicatie lijnen er doorlopen moeten worden, des te meer de overhead. In business software maakt dan tegenwoordig niet echt meer uit, maar in een high performance kernel zoals Linux merk je dat wel.
Die 'kunnen onterecht zijn jah. Bij binary distro's zoals Debian,Fedora,SuSE zit je al snel aan hun aangepaste kernel als je zelf niet wil knoeien en kan er bloatware(tm) in zitten, maar als je zelf je kernel compiled kan je er zoveel of zo weinig in zetten als je zelf wilt.

Als je iets niet wilt dan vink je het gewoon niet aan en komt er ook helemaal NIKS van in de kernel. Niks bloated dus :)
Een vraag waar ik al een tijd mee zit, als er steeds meer dingen aan de Linux kernel worden toegevoegd, wordt hij dan niet steeds meer 'bloated'?
Nee hoor, die zorgen zijn niet nodig.

Distributies zoals SuSE compileren alle functies als modules. Dat wil zeggen dat die functionaliteit alleen geladen wordt als het betreffende apparaat ook aanwezig is.
Toch blijven sommige mensen onzin posten
Leg dan wat uit waarom linux zo traag is :?
Ehh bijv een spelletje spelen op internet. Na een poosje surfen gaat alles toch wat trager en ehhh ik ben voor de rest een leek wat betreft Linux ;)
Dat ligt echt niet aan linux. Dat licht aan jouw installatie (misschien van flashplayer) of een bug in flashplayer oid, maar qua performance is linux juist beter dan windows. Kijk bijv. naar Unreal Tournament die zowel voor windows als linux is, op linux werkt ie veel sneller.
Linus has announced the release of the 2.6.20 kernel. "The half-time entertainment is provided by randomly inserted trivial syntax errors that nerds are expected to fix at home before completing the compile, but most people actually seem to mostly enjoy watching the compile warnings, sponsored by Anheuser-Busch, scroll past." There's a bunch of new stuff in 2.6.20, including paravirt_ops and KVM, lots of new drivers, the UDP-Lite protocol, Playstation 3 support, and more. See the short-form changelog for details, the long-format changelog for more details, the LWN 2.6 API changes page for a summary of internal API differences, or the KernelNewbies Linux Changes page for lots more information.
:)
Valt deze bug ook onder de intentional challenges?

CC [M] fs/nfs/dir.o
fs/nfs/dir.c: In function `nfs_access_add_cache':
include/asm/bitops.h:122: error: inconsistent operand constraints in an `asm'
make[2]: *** \[fs/nfs/dir.o] Error 1
make[1]: *** \[fs/nfs] Error 2
make: *** [fs] Error 2

Zo ja - ik vind 'm niet leuk.

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