From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MJRlX-00013W-WE
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:39:52 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MJRlS-0000wf-FS
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:39:51 -0400
Received: from [199.232.76.173] (port=52942 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MJRlS-0000wP-84
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:39:46 -0400
Received: from mx2.redhat.com ([66.187.237.31]:43516)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <amit.shah@redhat.com>) id 1MJRlR-0001VR-HL
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 08:39:45 -0400
Date: Wed, 24 Jun 2009 18:09:37 +0530
From: Amit Shah <amit.shah@redhat.com>
Message-ID: <20090624123937.GA14630@amit-x200.redhat.com>
References: <1245760953-32139-1-git-send-email-amit.shah@redhat.com>
	<200906241345.02051.rusty@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200906241345.02051.rusty@rustcorp.com.au>
Subject: [Qemu-devel] Re: virtio-serial: A guest <-> host interface for
	simple communication
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org

On (Wed) Jun 24 2009 [13:45:01], Rusty Russell wrote:
> On Tue, 23 Jun 2009 10:12:31 pm Amit Shah wrote:
> > Hello,
> >
> > Here are two patches. One implements a virtio-serial device in qemu
> > and the other is the driver for a guest kernel.
> >
> > While working on a vmchannel interface that is needed for communication
> > between guest userspace and host userspace, I saw that most of the
> > interface can be abstracted out as a "serial" device with "ports".
> 
> OK, I don't think the "naming" idea works though.  A userspace user would have 
> to open each one in turn to get its name.  I'd stick with numbers.

What if an ioctl were added to get the port number from the port name?
Userspace would do
	ioctl(fd, VIRTIO_SERIAL_GET_PORT_FROM_NAME, &nr);
	sprintf(port, "/dev/vmch%s", nr);
	fd2 = open(port, ...);

?

> You also don't have dynamic creation and removal, except by hotpluging the 
> entire device (which was on your requirements page).

Actually we're more interested in hotplugging ports than the device
itself ("Dynamic channel creation").

> what ports exist.  Register on the change interrupt to get updates.  Drop the 
> control vq entirely.

If the ioctl mentioned above were added, it would justify the control
vq, right?

Thanks for the comments,
		Amit