From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH][RFC] vmchannel a data channel between host and guest. Date: Tue, 14 Oct 2008 19:59:00 +0200 Message-ID: <20081014175900.GA18344@redhat.com> References: <20081012124534.GK11435@redhat.com> <48F39443.4070203@codemonkey.ws> <20081014090540.GB13153@redhat.com> <48F4A3B8.8050603@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , kvm@vger.kernel.org, Rusty Russell To: Anthony Liguori Return-path: Received: from il.qumranet.com ([212.179.150.194]:35434 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750989AbYJNR7D (ORCPT ); Tue, 14 Oct 2008 13:59:03 -0400 Content-Disposition: inline In-Reply-To: <48F4A3B8.8050603@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Oct 14, 2008 at 08:50:48AM -0500, Anthony Liguori wrote: > Gleb Natapov wrote: >> On Mon, Oct 13, 2008 at 01:32:35PM -0500, Anthony Liguori wrote: >> >>> >> netlink was designed to be interface to userspace and is used like this >> by different subsystems (not just network). What full blown socket (and >> by that I presume you mean new address family) will give you over netlink? >> File system? We need a simple stream semantics is this justify another >> virtual file system? The choice was between char device and netlink. >> Nelink was simpler and gives broadcast as a bonus. >> > > The problem that you aren't solving, that IMHO is critical to solve, is > the namespace issue. How do you determine who gets to use what channel > in userspace and in the host? Management software determines this. You have an image that is managed by particular software and management daemons on the guest knows what channels to use to communicate with their counterparts on the host. Is there a need to provide more then that? > It's not a problem when you just have one > tool, but if you expect people to start using this interface, > arbitrating it quickly becomes a problem. I expect that software on the host and on the guest will belong to the same management solution. > > sockets have a concept of addressing and a vfs has a natural namespace. > That's what I was suggesting those interfaces. > What address should look like if we will choose to use new address family? An example will help me understand what problem you are trying to point out easily. >> >>> Having a limit of only 4 links seems like a problem to me too. >>> >>> >> This can be easily extended. >> > > There shouldn't be an inherent limit in the userspace interface. > Well, qemu has those limits for all other interfaces (like number of nics, serial ports, parallel ports), but if vmchannels are somehow different in this regards there is no problem to dynamically grow their number. -- Gleb.