From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGcRy-0005yE-2M for qemu-devel@nongnu.org; Tue, 25 Sep 2012 17:13:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGcRx-0000lI-39 for qemu-devel@nongnu.org; Tue, 25 Sep 2012 17:13:49 -0400 Received: from mail-oa0-f45.google.com ([209.85.219.45]:37862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGcRw-0000l8-UP for qemu-devel@nongnu.org; Tue, 25 Sep 2012 17:13:49 -0400 Received: by oagi18 with SMTP id i18so2341280oag.4 for ; Tue, 25 Sep 2012 14:13:48 -0700 (PDT) From: Anthony Liguori In-Reply-To: <20120925155209.329c779e@doriath.home> References: <871uhqqif4.fsf@trasno.org> <873926p2rv.fsf@blackfin.pond.sub.org> <20120925155209.329c779e@doriath.home> Date: Tue, 25 Sep 2012 16:13:44 -0500 Message-ID: <87bogtolfb.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] KVM Call minutes for 2012-09-25 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino , Markus Armbruster Cc: qemu-devel@nongnu.org, KVM devel mailing list , quintela@redhat.com Luiz Capitulino writes: > 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. If we have a tool that needs to differientiate errors, chances are another user needs to also. Regards, Anthony Liguori