Linus Torvalds: Linux 2.6.31-rc1

Kernel

Linus bejelentette a 2.6.31-es kernel első kiadásra jelölt verzióját és ezzel egyben a 2.6.31-es kernel fejlesztési ciklusában a beolvasztási ablak bezárultát. Linus elégedett a "merge window" alatt tapasztaltakkal, a fejlesztők "tisztán" tartják a git fáikat és noha volt olyan, ahol azt mondta, hogy "nem, ezt nem fogom beolvasztani", összességében az egész beolvasztási időszak igazán "fájdalommentesnek" bizonyult.

Ahogy az már megszokott, a beolvasztott változtatások jelentős részét (a diff-ek mintegy 70%-a) az eszközmeghajtó-programok frissítése adja. Fájlrendszer fronton változások tapasztalhatók az ext3, btrfs, xfs környékén. Emellett architektúrákkal kapcsolatos változtatások és kisebb, mindenfelé előforduló bugfixek jellemzik az -rc1-et.

A bejelentés elolvasható itt.

( godot v | 2009. 06. 25., cs – 10:24 )

Csak a jegyzőkönyv kedvévért :) xen dom0 nincs.

Dübörögnek a pro és kontra érvek, de minenestre azért az 500K!! installált Xen nekem elég erős érvnek tűnik ha igaz. Az elavultság kérdésében nem tudok nyilatkozni.

Lehet, hogy elborult vagyok, de a Citrix fejlesztési kapacitásával + némi kp-val megtámogatva a NetBSD-t 1 éven belül ütős dom0 platformmá lehet kalapálni.
Azzal jönnek, hogy a linux überelhetetlen driver ellátottságban, de ki a f*szt érdekel egy dom0 platform esetén a víz alatt működő cdlejátszó és dedikált dobverő támogatás :), a network és storage cuccokon kéne lökni aztán kész.

Mondok párat:

Volume manager (az LVM portolása folyamatban, de nincs kész, illetve a ZFS portolási is folyamatban)
FC multipath
Cluster filesystem
Cluster megoldás ( gondolom az OpenAIS-t+pacemaker párost nem nagy vaszisztdasz portolni, de hát nincs meg.)
10G network kártyák

lvm ubernagyretek :(
FC ok elfogadom
cluster fs melyikre gondolsz?
cluster -> pont nem kell ha a domU an futo rendszerek clusterezve vannak(kulon gepeken nyilvan)

10G kartyak

nezd mi hasznalunk chelsiot linux alatt, es a linuxos driver kulonosen a TOE egy akkora retek h kb. hetente all bele a betonba, igazabol az IO load storage resze amugyis elviszi a gennybe a performanceot szal boven jo ha inkabb raksz bele 2 darab 1G-s kartyat vagy N darab 1G-s kartyat amihez mar van normalis driver

legalabbis meg nem lattam olyat hogy az lett volna a bottleneck h nincs 10G-s kartya :)

--
.

Értem én, hogy übernagyretek, de a tradicionális filesystem mellé valamit lvm-et választottak, és pl a kernel komponens teljes egészében új implementáció BSD licensszel.

Lustre pl?

A dom0 clusterezhetőség jól jöhet azért, nem fetétlen HA miatt, hanem pl valami elosztott dom0 architektúra? (agymenés on :) )

10G interfészek a konszolidáció miatt nagyon jók. (Kábel hell megszűnése, FCoE miatt is pl amit Cisco,EMC nagyon nyom stb, meg hát mindenképpen előremutató dolog.)

Elolvastam, tanulságos volt. Ezek után is azt mondom hogy ez nem Linus hibája. A cikk szerint a xen hypervisor nem túl jól lett megtervezve, ezért nem akarják beolvasztani.
Amúgy csinálhatna a xen is saját dom0-t, egy kicsit újabb kernelből (a 2.6.18 azért elég régi) szerintem abszolult nem lenne probléma, ha a xen fejlesztői minden tizedik kernelre irnának egy dom0-t. De ezt sem teszik. Csak szeretnék beolvasztani a mainline-ba persze a hiányzó hibajavítások nélkül.
Ezek után teljesen megértem Linus-t hogy miért nem engedi a beolvasztást. Ha beolvasztaná rögtön az ő felelőssége lenne hogy csináljanak vele valamit.

"A cikk szerint a xen hypervisor nem túl jól lett megtervezve"

HAHAHHAHA

ev poenja, ugyerted mar elev az derogalo linusnak hogy valaki tervezett programmal jon es nem csak onthefly implemental valamit aztan 2 hetente cserelgeti a tejes strukturat?

mert ha ezt gondolod es ilyen extrem humoros vagy akkor OK
--
.

Nem lehet Xen a kernelben, mert akkor a Redhat kis kedvencéről baromi gyorsan kiderülne, hogy sehol sincs hozzá képest menedzselhetőségben. :I

Aha, ja nem is, meg van a cikkből a valódi oka:

"...and in user space - with, of course, a set-in-concrete user-space ABI in the middle."

"One of Thomas's complaints (and a valid one) is that once Linux supports an external API it must always keep it compatible."

Azt a mindenit, esetleg kénytelenek lesznek olyan _valóban_ enterspájz fícsöröket bevezetni, amiket a Solaris és - Uram bocsá! - a Windows már régóta tud: pl. egy 10 éves programot jó eséllyel változtatás nélkül futtathatsz rajtuk? :))

A vége meg úgyis az lesz, hogy a kereskedelmilinux-gyártók kénytelenek lesznek a Xent belerakni, mert az ügyfeleiknek az kell. Lassan a Linuxszal kapcsolatban olyan érzésem van, hogy ugyanúgy a fejlesztők játszótere, mint az OpenBSD. Csak ez utóbbiban ezt tudatosan fölvállalják és kommunikálják is, nem játsszák az eszüket (annyira :), hogy enterspájz oprendszert kalapálunk. :/

--
Wir sind erfasst, sind infiziert
Jedes Gespräch wird kontrolliert.

varjal te zambori zoltan enterspajz linux fejlesztovel beszelgetsz a jovo lehetseges virtualizacios platformjarol?

allitolag supportalt lesz az adott pozicioban becsukott calc exe ugyanottmegjelenese, meg ddos allo is lesz, meg ugyhallottam csomo egyeb enterspajz ficsort fog meg felvonultatni azok alapjan hogy az izraeli desktop virtualizaciora szakosodott ceg lett rakuldve a feladatra(erdekes h foss fejlesztok nem jeleskednek ezen a teren)

--
.

> "One of Thomas's complaints (and a valid one) is that once Linux supports an external API it must always keep it compatible."

Na nem már, minden izgalmat elvesznek az embertől. Hol marad itt a csomagfrissítés utáni, "na most mi nem fog menni" izgalom?

Mondjuk azt tudnám díjazni, hogy ha a Neverwinter Nights elindulna, ha már egyszer direkt azért vettem meg, mert Linuxra is megjelent, és tetszett nekem. Ez van :(

Van -e olyan technikai erv mely szerint a KVM felepitesebol kifojolak nem tudd jobb teljesitmenyt elerni mint a Xen ?

egyreszrol KVM eseteben nincsen valodi hipervisor, azaz maga a minden egyeb sz@rral telezsufolt linux kernel az, ami a guestek teljeskoru kezeleseert felel, mig xen alatt a dom0-ban futo linuxon gyakorlatilag csak a guestek i/o keresei futnak at, minden masert egy kicsi, egyszeru, hatekony kulonallo hipervisor reteg (gyak. egy mikrokernel) felel.

masreszrol KVM most sem tud teljesen paravirtualizalt guesteket kezelni ahol tenyleg minden, amugy koltseges emulaciot igenylo feladat egyszeruen at lenne passzolva a host kernelnek. Ebbol kifolyolag kernelforditas eseten pld. boven mertem mar 100%-os teljesitmenykulonbseget a xen alatt futo guestek javara.

FIXME: KVM IO -ban most is jobb.

pv block I/O-t hasznalni kepes guesteknel (Linux) elkepzelhetonek tartom, de az a teny hogy Win* ala xenhez letezik pv I/O-t hasznalo block device driver kvmhez meg csak network driver, az onmagaban elegge hihetetlenne teszi a fenti kijelentesedet.

Ez elso pontot ertelmezhetem -e igy:
Hypervisor utemzi CPU idot a guestek kozott es osztja ki memoriat, onmagban nem kepes filerendszert kezelni,swapet hasznalni, vagy halozati csomagot kuldeni.

A guestek IO kerese egy Xen hipervisornyival hosszabb hivasi lancon megy keresztul, s vegul dom0 (Linux) kernel vegzi el.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

The virtual drivers that Xen exposes to its domains run in a special VM, dom0. Each time the virtual drivers in dom0 needs to manage for example multiplexing of a packet from the network driver, the VMM scheduler switches to dom0 kernel space, and the packet is multiplexed in dom0 userspace. Receiving this packet in domU thus incurs at least six context switches: domU -> VMM scheduler -> dom0 kernel space -> dom0 user space -> dom0 kernel space -> VMM scheduler -> domU

KVM is not really a monolithic hypervisor, either. But it's closer: VM -> Linux kernel space -> Linux user space -> Linux kernel space -> VM

A monolithic hypervisor would multiplex drivers in the same address space as the VMM, and only two context switches would be incurred: VM -> VMM space -> VM

( padawan | 2009. 06. 25., cs – 11:11 )

Faszan el is hal boot alatt i915_* mokakkal ;)