linux-kernel - Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

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]

Message-ID: <20091222075927.GC26467@elte.hu>
Date:	Tue, 22 Dec 2009 08:59:27 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Anthony Liguori <anthony@...emonkey.ws>
Cc:	Gregory Haskins <gregory.haskins@...il.com>,
	Avi Kivity <avi@...hat.com>, kvm@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org,
	"alacrityvm-devel@...ts.sourceforge.net" 
	<alacrityvm-devel@...ts.sourceforge.net>
Subject: Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

* Anthony Liguori <anthony@...emonkey.ws> wrote:

> It's important to understand why one mechanism is better than another.  All 
> I'm looking for is a set of bullet points that say, vbus does this, 
> vhost-net does that, therefore vbus is better.  We would then either say, 
> oh, that's a good idea, let's change vhost-net to do that, or we would say, 
> hrm, well, we can't change vhost-net to do that because of some fundamental 
> flaw, let's drop it and adopt vbus.
> 
> It's really that simple :-)

That makes a lot of sense to me.

I think we better have damn good technical reasons before we encourage a fork 
of a subsystem within the kernel. Technical truth is not something we can 
'agree to disagree' on, and it is not something we can compromise on really.  

Both the host and the guest code is in Linux so adding another variant without 
that variant replacing the old one (on the spot or gradually) makes no 
technical sense.

Gregory, i'd suggest for you to shape this as a "this and this aspect of KVM 
needs to be replaced/fixed" list of items, as suggested by Anthony. In my 
experience the KVM folks are very approachable and very reasonable about 
addressing technical shortcomings and acting upon feedback (and are happily 
accepting code as well) - so to the extent there's room for improvement here 
it should be done by shaping KVM, not by forking and rebranding it.

	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/