From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaQEh-00069S-PK for qemu-devel@nongnu.org; Fri, 11 Sep 2015 11:27:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaQEd-0007JJ-OG for qemu-devel@nongnu.org; Fri, 11 Sep 2015 11:27:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50730) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaQEd-0007G9-Hf for qemu-devel@nongnu.org; Fri, 11 Sep 2015 11:27:31 -0400 References: From: Eric Blake Message-ID: <55F2F2E0.4030006@redhat.com> Date: Fri, 11 Sep 2015 09:27:28 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bMXjHnAmFsTu0Ww9Rik3adc3xxGnv8QcV" Subject: Re: [Qemu-devel] [RFC PATCH v1 00/25] error: Automatic error concatenation and prefixing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, armbru@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bMXjHnAmFsTu0Ww9Rik3adc3xxGnv8QcV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/10/2015 11:33 PM, Peter Crosthwaite wrote: > Hi Markus and all, >=20 > This patch series adds support for automatically concatenating multiple= > errors to the one Error *. Sounds interesting! > So the plan is: >=20 > 1: Allow an Error * to contain more that one actual error from API > calls. Is this for all errors, or do you have to make a special call to make it obvious that a particular error can be concatenated to while the default is still to report programming error if a second error is attempted atop a regular error that hasn't requested concatenation? > 2: Refactor key APIs (some_similar_api_call() in the above example) > to not fatal when previous errors have occured in dependencies. >=20 > Point 1 kind of got big on me. Patch 4 is the main event, listifying > errors. The follow up issue however, is it tricky to get a sane > definition of error_get_pretty for a multi-error. So instead the > strategy is to remove error_get_pretty() and replace with some error > API helper with well defined behaviour for multi-error. The two leading= > uses of error get pretty are prefixing an error, and reporting an error= > via a custom printf handler. So two new APIs are added for that (P5-6).= > There aren't many error_get_pretty's left after that, and they > shouldn't be in the path of any multi-errors. >=20 > I think the error_prefix is valuable it its own right, as it now means > the code for report or propagating a prefixed error is now consistent > with the non-prefixed variants. >=20 > That is, we used to have: >=20 > /* If we are prefixing we have to do it this way: */ > error_setg(errp, "some prefix %s", error_get_pretty(local_err)); > error_free(local_err); >=20 > vs: >=20 > /* but if not prefixing it is like this: */ > error_propagate(errp, local_err); >=20 > Now with this patch series the two are much more recognisable as the sa= me > with: >=20 > /* This code is almost the same as the above non-prefixed propagation *= / > error_prefix(local_err, "some prefix"): > error_propagate(errp, local_err); Seems nice in its own right. >=20 > Point 2 is less about error API and more about machine generation. > Sysbus, Memory and Qdev all have APIs that depend on successful device-= > init and realize calls for argument devices. As we are trying to remove= > the error detection for those argument devs, those APIs need to tweaked= > to handle realize failure. This actually wasn't as bad as I thought it > would be. See patches (7-9). >=20 > All patches after that walk the various major subsystems converting > error APIs to this new scheme and deleting now-unneeded boiler plate. > ARM is first (P10-15) seeing good clean up of propagate handers. >=20 > So the net result for these ARM machines, is error behaviour that is > something like a compiler. If any one thing fails, then machine-init > (compilation) fails. But an early fail does not stop machine-init > (compilation), instead it proceeds to the end collecting subsequent > errors as it goes. Sometimes that causes more problems (ignoring an error and proceeding on can cause confusing followup errors), but usually it manages to work out.= >=20 > Some other interesting food for thought is the qemu_fdt APIs which I > have been wanting to convert to error API but the local_err propagation= > is going to be brutal in heavy users like e500.c. This would solve that= > as fdt API could be easily made multi-error safe and clients like e500 > can just collect multi-errors and single-fail at the end. >=20 > Long term, we can use this to catch cases of multiple genuine machine > init errors in the one boot but that is a secondary goal to simply > cutting down on code boilerplate. The best feature of this series is > the diffstat. >=20 > Patches 1-3 are cleanup that can be taken independent of the series. >=20 > I think P3 may be obsolete from a recent merge, but i'll wait > for architectural feedback before rebasing. Yeah, both Markus and I have been touching error.c lately, so a rebase will probably be needed. >=20 > Regards, > Peter > --END--- >=20 > Signed-off-by: Peter Crosthwaite > --- > __HAS_COVER__ | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) > create mode 100644 __HAS_COVER__ >=20 > diff --git a/__HAS_COVER__ b/__HAS_COVER__ > new file mode 100644 > index 0000000..e69de29 >=20 Huh - whatever you are using to version your cover letter made the real diffstat be part of the signature rather than the main body of the email.= --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --bMXjHnAmFsTu0Ww9Rik3adc3xxGnv8QcV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJV8vLgAAoJEKeha0olJ0NqjpgH/3JKliq2ffkC40lyzTgyU8Lj Sbh2zX5BolvTMH65pSYBYn+hRGfQHkCkzWyON8YwsNcmd/9W4nnlWL6HxK6PfpXT i6Dj6oX+wahM7TTFp7oRG6gUwUCB+WSbaCr15NVlpCAP3lvcjReiqnwIhXgfldSD RSg0crudUbMzDbLj8lhjkxILHnJ5+VBg4mhSWBPwLyCiHbt7ZKDqYKJomGdEitzz 1opWDK+wonYUxtQVLPM2ZEpGKfkegh08Oytwo3UinOTJcTzJXA4iq/+XY18mL2Os QyV+M1Kmx5yWW7uMibisaVoTNYnK54qjemcUETX4wGVdi/26ja/nP+fgFclfQCI= =6xuL -----END PGP SIGNATURE----- --bMXjHnAmFsTu0Ww9Rik3adc3xxGnv8QcV--