[GEDI] [PATCH v4 04/31] error: auto propagated local_err
Vladimir Sementsov-Ogievskiy
vsementsov at virtuozzo.com
Wed Oct 9 08:17:44 UTC 2019
09.10.2019 11:04, Markus Armbruster wrote:
> Vladimir Sementsov-Ogievskiy <vsementsov at virtuozzo.com> writes:
>
>> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
>> functions with errp OUT parameter.
>>
>> It has three goals:
>>
>> 1. Fix issue with error_fatal & error_prepend/error_append_hint: user
>> can't see this additional information, because exit() happens in
>> error_setg earlier than information is added. [Reported by Greg Kurz]
>
> Done in PATCH 07-31.
>
>> 2. Fix issue with error_abort & error_propagate: when we wrap
>> error_abort by local_err+error_propagate, resulting coredump will
>> refer to error_propagate and not to the place where error happened.
>> (the macro itself doesn't fix the issue, but it allows to [3.] drop all
>> local_err+error_propagate pattern, which will definitely fix the issue)
>> [Reported by Kevin Wolf]
>>
>> 3. Drop local_err+error_propagate pattern, which is used to workaround
>> void functions with errp parameter, when caller wants to know resulting
>> status. (Note: actually these functions could be merely updated to
>> return int error code).
>
> Not done. Can you prototype this part? A few manually done examples
> would give us an idea how the complete solution would look like. A
> (semi-)automated complete conversion of a subsystem would additionally
> give us an idea how to actually do the conversion.
>
> We can discuss applying ERRP_AUTO_PROPAGATE() as a bug fix for 1., and
> leave 2. and 3. for later. Feels like a half-done job to me. We've got
> too many of those in the tree already. Dunno.
>
If update everything it's about 90-140 patches.
The whole thing was done in "[RFC v2 0/9] error: auto propagated local_err"
<20190923161231.22028-1-vsementsov at virtuozzo.com>
https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg05157.html
- it was so huge, that I decided to postpone 2 and 3...
--
Best regards,
Vladimir
More information about the integration
mailing list