From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NV806-000288-M8 for qemu-devel@nongnu.org; Wed, 13 Jan 2010 13:31:26 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NV802-000262-PC for qemu-devel@nongnu.org; Wed, 13 Jan 2010 13:31:26 -0500 Received: from [199.232.76.173] (port=59443 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NV802-00025p-8z for qemu-devel@nongnu.org; Wed, 13 Jan 2010 13:31:22 -0500 Received: from qw-out-1920.google.com ([74.125.92.149]:7664) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NV801-0004JY-OW for qemu-devel@nongnu.org; Wed, 13 Jan 2010 13:31:21 -0500 Received: by qw-out-1920.google.com with SMTP id 14so341308qwa.4 for ; Wed, 13 Jan 2010 10:31:20 -0800 (PST) Message-ID: <4B4E116A.1040206@codemonkey.ws> Date: Wed, 13 Jan 2010 12:31:06 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 5/8] virtio-serial-bus: Add support for buffering guest output, throttling guests References: <1262849506-27132-6-git-send-email-amit.shah@redhat.com> <20100108011231.GA5011@shareable.org> <20100108050351.GB8999@amit-x200.redhat.com> <20100108133503.GA19328@shareable.org> <20100111083443.GA6061@amit-x200.redhat.com> <20100111104553.GA4746@shareable.org> <20100111110410.GA13658@amit-x200.redhat.com> <20100111233356.GB30714@shareable.org> <20100112071612.GB19438@amit-x200.redhat.com> <4B4C8EA4.9080106@codemonkey.ws> In-Reply-To: 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: Markus Armbruster Cc: Amit Shah , qemu-devel@nongnu.org On 01/13/2010 11:14 AM, Markus Armbruster wrote: > Anthony Liguori writes: > > >> On 01/12/2010 01:16 AM, Amit Shah wrote: >> >>> BTW I don't really want this too, I can get rid of it if everyone agrees >>> we won't support clipboard writes> 4k over vnc or if there's a better >>> idea. >>> >>> >> Why bother trying to preserve message boundaries? I think that's the >> fundamental question. >> > Yes. Either it's a datagram or a stream pipe. I always thought it > would be a stream pipe, as the name "serial" suggests. > And if it's a datagram, then we should accept that there will be a fixed max message size which is pretty common in all datagram protocols. That fixed size should be no larger than what the transport supports so in this case, it would be 4k. If a guest wants to send larger messages, it must build a continuation protocol on top of the datagram protocol. Regards, Anthony Liguori