From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mt45c-0005jj-St for qemu-devel@nongnu.org; Wed, 30 Sep 2009 14:39:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mt45Y-0005hx-B7 for qemu-devel@nongnu.org; Wed, 30 Sep 2009 14:39:48 -0400 Received: from [199.232.76.173] (port=39428 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mt45Y-0005hq-4A for qemu-devel@nongnu.org; Wed, 30 Sep 2009 14:39:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48518) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mt45X-00082R-2f for qemu-devel@nongnu.org; Wed, 30 Sep 2009 14:39:43 -0400 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8UIdbo9024328 for ; Wed, 30 Sep 2009 14:39:37 -0400 Message-ID: <4AC3A5E6.6070703@redhat.com> Date: Wed, 30 Sep 2009 20:39:34 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 3/6] virtio-console: Add a virtio-console bus, support for multiple ports References: <1254225888-17093-1-git-send-email-amit.shah@redhat.com> <1254225888-17093-2-git-send-email-amit.shah@redhat.com> <1254225888-17093-3-git-send-email-amit.shah@redhat.com> <1254225888-17093-4-git-send-email-amit.shah@redhat.com> <4AC24C34.2080609@redhat.com> <20090930044724.GA28188@amit-x200.redhat.com> <4AC31E03.8000904@redhat.com> <20090930155534.GB1011@amit-x200.redhat.com> In-Reply-To: <20090930155534.GB1011@amit-x200.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: qemu-devel@nongnu.org > BTW the kernel too doesn't support multiple devices so far. Needs fixing too ;) >> I'd suggest to look what do do when another user which wants buffering >> comes along. Might be the requirements are different, so it wouldn't >> work anyway. >> >> Also when you pass around pointers to VirtConPortBuffer the port drivers >> can implement buffering very easily. > > It will mostly be duplicated. Right now, I pass on an entire message as > was passed on by the kernel in one write() request. If I start passing > around buffers, it'll be incomplete messages (eg, an 8K write request in > the kernel will be split in two buffers of 4K each -- or three buffers > with the last one containing a few bytes). I don't think I want the ports > to worry about that. The ports should just get the entire message. Sure. I think there is a misunderstanding here. I meant only the "buffer messages when unconnected" thing. Reassembling the messages in the core and forward only complete messages to the ports is fine. > So I don't think I want to expose the buffers to individual devices. My idea was to pass the (reassembled) message to the port drivers in a form they can just stick into a list without memcpy()ing the message in case they want to keep it. Maybe to buffer it because the chardev is unconnected. Maybe just keep the most recent message because it contains some kind of guest status. VirtConPortBuffer looked like it could do the job. Well, not perfectly, it has extra status which is needed only by the core for reassembling messages. >> They are handled differently though. I think console will not do any >> buffering at all, whereas serial-port provides the option to do >> buffering. > > But the buffering is independent of the char drivers. See above ;) > Basically I've now dropped the old -virtioconsole argument. > > So one has to do: > > -device virtio-console-pci -device virtioconsole ... > > to start a console. If you do '-device virtio-console-pci -device virtio-port' (i.e. no console) and boot a old guest kernel which expects a (single) console being there, what will happen? cheers, Gerd