From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJnCh-0004ge-Ty for qemu-devel@nongnu.org; Thu, 25 Jun 2009 07:33:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJnCd-0004fP-3y for qemu-devel@nongnu.org; Thu, 25 Jun 2009 07:33:19 -0400 Received: from [199.232.76.173] (port=36082 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJnCb-0004fD-TD for qemu-devel@nongnu.org; Thu, 25 Jun 2009 07:33:14 -0400 Received: from ozlabs.org ([203.10.76.45]:59961) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJnCb-0000j9-Bb for qemu-devel@nongnu.org; Thu, 25 Jun 2009 07:33:13 -0400 From: Rusty Russell Date: Thu, 25 Jun 2009 21:03:02 +0930 References: <1245760953-32139-1-git-send-email-amit.shah@redhat.com> <200906241345.02051.rusty@rustcorp.com.au> <20090624123937.GA14630@amit-x200.redhat.com> In-Reply-To: <20090624123937.GA14630@amit-x200.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906252103.02892.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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org On Wed, 24 Jun 2009 10:09:37 pm Amit Shah wrote: > 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, ...); Yep, pretty ugly tho. If you use the "Amit Shah is in charge of port numbering approach", then it's just: fd = open("/dev/vmch", ...); Since you need to control names anyway, why not just use numbers? > > 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"). Exactly, which you don't seem to have. > > 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? Yes. Or put another way, simplifying the interface to use assigned port numbers would simplify the implementation, use, and specification of the device :) Cheers, Rusty.