From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: virtio-serial: A guest <-> host interface for simple communication Date: Thu, 25 Jun 2009 21:03:02 +0930 Message-ID: <200906252103.02892.rusty@rustcorp.com.au> References: <1245760953-32139-1-git-send-email-amit.shah@redhat.com> <200906241345.02051.rusty@rustcorp.com.au> <20090624123937.GA14630@amit-x200.redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: virtualization@lists.linux-foundation.org, qemu-devel@nongnu.org, kvm@vger.kernel.org To: Amit Shah Return-path: Received: from ozlabs.org ([203.10.76.45]:43887 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752111AbZFYLdE (ORCPT ); Thu, 25 Jun 2009 07:33:04 -0400 In-Reply-To: <20090624123937.GA14630@amit-x200.redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: 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.