From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGaE4-0006l6-Bv for qemu-devel@nongnu.org; Tue, 25 Sep 2012 14:51:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGaE3-00033H-CR for qemu-devel@nongnu.org; Tue, 25 Sep 2012 14:51:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGaE3-00033A-49 for qemu-devel@nongnu.org; Tue, 25 Sep 2012 14:51:19 -0400 Date: Tue, 25 Sep 2012 15:52:09 -0300 From: Luiz Capitulino Message-ID: <20120925155209.329c779e@doriath.home> In-Reply-To: <873926p2rv.fsf@blackfin.pond.sub.org> References: <871uhqqif4.fsf@trasno.org> <873926p2rv.fsf@blackfin.pond.sub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] KVM Call minutes for 2012-09-25 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, KVM devel mailing list , quintela@redhat.com On Tue, 25 Sep 2012 16:59:00 +0200 Markus Armbruster wrote: > Juan Quintela writes: > > > Hi > > > > This are this week minutes: > > > > - URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the > > same code. (Paolo) > > * code hasn't changed in 2 years, it is really stable > > * anthony wants to copy the code > > > > - there are several commands that do blocking IO > > dump-guest-memory/screen-dump > > convert to asynchronous commands after we move all to QAPI > > only two commands missingto port to QAPI, and one is posted on list > > non-blocking IO to a file is a challenge > > (we have code on the block layer for it) > > > > - how to give errors from OpenFile to the caller > > putting errno as int: bad idea > > putting as strerrno string: also a bad idea, no warantees > > Use the identifiers instead of their non-portable numeric encodings or > strerror() descriptions: "EPERM", "EINVAL", ... Yes, but for me the important point in this discussion is whether or not a new class is necessary. I think it it isn't.