From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: KVM Call minutes for 2012-09-25 Date: Tue, 25 Sep 2012 16:59:00 +0200 Message-ID: <873926p2rv.fsf@blackfin.pond.sub.org> References: <871uhqqif4.fsf@trasno.org> Mime-Version: 1.0 Content-Type: text/plain Cc: KVM devel mailing list , qemu-devel@nongnu.org To: quintela@redhat.com Return-path: Received: from mx1.redhat.com ([209.132.183.28]:64099 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753453Ab2IYO7D (ORCPT ); Tue, 25 Sep 2012 10:59:03 -0400 In-Reply-To: <871uhqqif4.fsf@trasno.org> (Juan Quintela's message of "Tue, 25 Sep 2012 16:35:43 +0200") Sender: kvm-owner@vger.kernel.org List-ID: 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", ... > Using an extended error code > Put it as a string that can be parsed? > Paolo suggest to create a new error class > We don't warantee that errors would be "parseable". We don't want programs to parse the human-readable error string.