Eric Blake <ebl...@redhat.com> writes: > On 11/11/2015 07:21 AM, Markus Armbruster wrote: >> Eric Blake <ebl...@redhat.com> writes: >> >>> A few uses of error_set(ERROR_CLASS_GENERIC_ERROR) have snuck in >>> since c6bd8c706. Nuke them. >> >> Doesn't really belong to this series, but that's okay. > > If you're going to modify this for 2.5 inclusion through your qerror > tree, you may want to change the description to:
I'll try to get this into 2.5 mostly for the documentation update. > A few uses of error_set(ERROR_CLASS_GENERIC_ERROR) were missed in > c6bd8c706, or have snuck in since. Nuke them. Done. >>> +++ b/hw/i386/pc.c >>> @@ -1795,7 +1795,7 @@ static void pc_machine_set_max_ram_below_4g(Object >>> *obj, Visitor *v, >>> return; >>> } >>> if (value > (1ULL << 32)) { >>> - error_set(&error, ERROR_CLASS_GENERIC_ERROR, >>> + error_setg(&error, >>> "Machine option 'max-ram-below-4g=%"PRIu64 >>> "' expects size less than or equal to 4G", value); >> >> Indentation is now off. Can tidy up in my tree. >> >>> error_propagate(errp, error); >> [Rest snipped, it looks good] >> > > There's also the question if we want to address the ErrorClass name > munging of 19/28 by adding your idea of an aliasing typedef in error.h; > if so, should I prepare a smaller patch series of both of those changes > for consideration for 2.5? Can safely wait for 2.6, can't it?