From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ6nQ-0007T9-Fo for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:16:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ6nL-0007M0-M4 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:16:23 -0400 Received: from [199.232.76.173] (port=50548 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ6nL-0007Lm-HV for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:16:19 -0400 Received: from mx20.gnu.org ([199.232.41.8]:12029) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJ6nL-0003rQ-9Z for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:16:19 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ6nK-0001oX-9j for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:16:18 -0400 From: Paul Brook Subject: Re: [Qemu-devel] virtio-serial: A guest <-> host interface for simple communication Date: Tue, 23 Jun 2009 15:16:13 +0100 References: <1245760953-32139-1-git-send-email-amit.shah@redhat.com> <200906231355.53557.paul@codesourcery.com> <200906231558.33794.borntraeger@de.ibm.com> In-Reply-To: <200906231558.33794.borntraeger@de.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906231516.15470.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian =?iso-8859-1?q?Borntr=E4ger?= Cc: Amit Shah , qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org On Tuesday 23 June 2009, Christian Borntr=E4ger wrote: > Am Dienstag 23 Juni 2009 14:55:52 schrieb Paul Brook: > > > Here are two patches. One implements a virtio-serial device in qemu > > > and the other is the driver for a guest kernel. > > > > So I'll ask again. Why is this separate from virtio-console? > > I did some work on virtio-console, since kvm on s390 does not provide any > other. I dont think we should mix two different types of devices into one > driver. The only thing that these drivers have in common, is the fact that > there are two virtqueues, piping data (single bytes or larger chunks). So > you could make the same argument with the first virtio_net driver (the one > before GSO) - which is obviously wrong. The common part of the transport = is > already factored out to virtio_ring and the transports. virtio-net is packet based, not stream based. > In addition there are two ABIs involved: a userspace ABI (/dev/hvc0) and a > guest/host ABI for this console. (and virtio was not meant to be a KVM-on= ly > interface, that we can change all the time). David A. Wheeler's 'SLOCCoun= t' > gives me 141 lines of code for virtio_console.c. I am quite confident that > the saving we could achieve by merging these two drivers is not worth the > hazzle. AFAICS the functionality provided is exactly the same. The host API is=20 identical, and the guest userspace API only has trivial differences (which= =20 could be eliminated with a simple udev rule). By my reading virtio-serial=20 makes virtio-console entirely redundant. > Discussion about merging the console code into this distracts from the ma= in > problem: To get the interface and functionality right before it becomes an > ABI (is it /dev/ttyS, network like or is it something completely > different?). Ah, now that's a different question. I don't know what the requirements are= =20 for the higher level vmchannel interface. However I also don't care. Paul