linux-kernel - Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus

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: <4A8AB076.6080906@redhat.com>
Date:	Tue, 18 Aug 2009 16:45:26 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Gregory Haskins <gregory.haskins@...il.com>
CC:	Anthony Liguori <anthony@...emonkey.ws>,
	Ingo Molnar <mingo@...e.hu>,
	Gregory Haskins <ghaskins@...ell.com>, kvm@...r.kernel.org,
	alacrityvm-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver
 objects

On 08/18/2009 04:16 PM, Gregory Haskins wrote:
> The issue here is that vbus is designed to be a generic solution to
> in-kernel virtual-IO.  It will support (via abstraction of key
> subsystems) a variety of environments that may or may not be similar in
> facilities to KVM, and therefore it represents the
> least-common-denominator as far as what external dependencies it requires.
>    

Maybe it will be easier to evaluate it in the context of these other 
environments.  It's difficult to assess this without an example.

> The bottom line is this: despite the tendency for people to jump at
> "don't put much in the kernel!", the fact is that a "bus" designed for
> software to software (such as vbus) is almost laughably trivial.  Its
> essentially a list of objects that have an int (dev-id) and char*
> (dev-type) attribute.  All the extra goo that you see me setting up in
> something like the kvm-connector needs to be done for fast-path
> _anyway_, so transporting the verbs to query this simple list is not
> really a big deal.
>    

It's not laughably trivial when you try to support the full feature set 
of kvm (for example, live migration will require dirty memory tracking, 
and exporting all state stored in the kernel to userspace).

> Note that I didn't really want to go that route.  As you know, I tried
> pushing this straight through kvm first since earlier this year, but I
> was met with reluctance to even bother truly understanding what I was
> proposing, comments like "tell me your ideas so I can steal them", and
>    

Oh come on, I wrote "steal" as a convenient shorthand for 
"cross-pollinate your ideas into our code according to the letter and 
spirit of the GNU General Public License".  Since we're all trying to 
improve Linux we may as well cooperate.

> "sorry, we are going to reinvent our own instead".

No.  Adopting venet/vbus would mean reinventing something that already 
existed.  Continuing to support virtio/pci is not reinventing anything.

> This isn't exactly
> going to motivate someone to continue pushing these ideas within that
> community.  I was made to feel (purposely?) unwelcome at times.  So I
> can either roll over and die, or start my own project.
>    

You haven't convinced me that your ideas are worth the effort of 
abandoning virtio/pci or maintaining both venet/vbus and virtio/pci.  
I'm sorry if that made you feel unwelcome.  There's no reason to 
interpret disagreement as malice though.

-- 
error compiling committee.c: too many arguments to function

--
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/