From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MJJtB-0001uL-P1
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 00:15:13 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MJJt7-0001s1-5F
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 00:15:13 -0400
Received: from [199.232.76.173] (port=35505 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MJJt6-0001rp-V7
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 00:15:09 -0400
Received: from ozlabs.org ([203.10.76.45]:42009)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <rusty@rustcorp.com.au>) id 1MJJt6-0004SA-HH
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 00:15:08 -0400
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Wed, 24 Jun 2009 13:45:01 +0930
References: <1245760953-32139-1-git-send-email-amit.shah@redhat.com>
In-Reply-To: <1245760953-32139-1-git-send-email-amit.shah@redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <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: virtualization@lists.linux-foundation.org
Cc: Amit Shah <amit.shah@redhat.com>, qemu-devel@nongnu.org, kvm@vger.kernel.org

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.

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

I'd put a size and bitmap in the configuration space, and use that to indicate 
what ports exist.  Register on the change interrupt to get updates.  Drop the 
control vq entirely.

Cheers,
Rusty.