linux-kernel - Re: [RFC] Unify KVM kernel-space and user-space code into a single project

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Mar 2010 15:36:56 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	"Frank Ch. Eigler" <fche@...hat.com>,
	Alexander Graf <agraf@...e.de>,
	Anthony Liguori <anthony@...emonkey.ws>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project

* Avi Kivity <avi@...hat.com> wrote:

> > Happy choice or not, this is what i said is the distro practice these 
> > days. (i dont know all the distros that well so i'm sure there's 
> > differences)
> 
> So in addition to all the normal kernel regressions, you want to force 
> tools/kvm/ regressions on users.

So instead you force a NxN compatibility matrix [all versions of qemu combined 
with all versions of the kernel] instead of a linear N versions matrix with a 
clear focus on the last version. Brilliant engineering i have to say ;-)

Also, by your argument the kernel should be split up into a micro-kernel, with 
different packages for KVM, scheduler, drivers, upgradeable separately.

That would be a nightmare. (i can detail many facets of that nightmare if you 
insist but i'll spare the electrons for now) Fortunately few kernel developers 
share your views about this.

> > > I don't mind at all if rawhide users run on the latest and greatest, but 
> > > release users deserve a little more stability.
> >
> > What are you suggesting, that released versions of KVM are not reliable? 
> > Of course any tools/ bits are release engineered just as much as the rest 
> > of KVM ...
> 
> No, I am suggesting qemu-kvm.git is not as stable as released versions (and 
> won't get fixed backported).  Keep in mind that unlike many userspace 
> applications, qemu exposes an ABI to guests which we must keep compatible.

I think you still dont understand it: if a tool moves to the kernel repo, then 
it is _released stable_ together with the next stable kernel.

I.e. you'd get a stable qemu-2.6.34 in essence, when v2.6.34 is released. You 
get minor updates with 2.6.34.1, 2.6.34.2, 2.6.34.3, etc - while development 
continues.

I.e. you get _more_ stability, because a matching kernel is released with a 
matching Qemu.

Qemu might have a different release schedule. Which, i argue, is not a good 
thing for exactly that reason :-) If it moved to tools/kvm/ it would get the 
same 90 days release frequency, merge window and stabilization window 
treatment as the upstream kernel.

Furthermore, users can also run experimental versions of qemu together with 
experimental versions of the kernel, by running something like 2.6.34-rc1 on 
Rawhide. Even if they dont download the latest qemu git and build it.

I.e. clearly _more_ is possible in such a scheme.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/