From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] qemu: qemu_fopen_fd: differentiate between reader and writer user Date: Wed, 15 Oct 2008 23:10:19 -0500 Message-ID: <48F6BEAB.1060705@codemonkey.ws> References: <1223829030-14962-1-git-send-email-uril@qumranet.com> <48F22BF1.3000608@redhat.com> <48F68746.8010904@il.qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Uri Lublin , kvm@vger.kernel.org To: Uri Lublin Return-path: Received: from mail-gx0-f16.google.com ([209.85.217.16]:36771 "EHLO mail-gx0-f16.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750773AbYJPEKY (ORCPT ); Thu, 16 Oct 2008 00:10:24 -0400 Received: by gxk9 with SMTP id 9so7827760gxk.13 for ; Wed, 15 Oct 2008 21:10:23 -0700 (PDT) In-Reply-To: <48F68746.8010904@il.qumranet.com> Sender: kvm-owner@vger.kernel.org List-ID: Uri Lublin wrote: >> >> Anthony, this is a problem with qemu-upstream so I'd like to solve it >> in a way that's acceptable for upstream. >> >> The proposed patch is less that ideal IMO as it introduces >> limitations on what you can do with a file. An alternative >> implementation would add a read/write mode to the buffer, based on >> the last access type. When switching from read to write, we drop the >> buffer, and when switching from write to read, we flush it and then >> drop it. This is more complex but results in a cleaner API. >> > > I am not sure we are allowed to drop the buffer a on read-to-write > switch, especially if there are unread bytes in it. We may need to > pause the write that causes the switch, similar to pausing the read in > order to flush the buffer on a write-to-read switch. Yeah, I tried to implement the read/write mode buffer and it ends up not to work very nicely. I don't remember the precise issue, but I hit some sort of wall that I thought was a fundamental limitation. I ended up forcing the QEMUFile to be in either read or write mode similar to your original patch without introducing a new option as an argument. Regards, Anthony Liguori