Re: [PATCH v2 2/2] migration: vmsd errp handlers: return bool

[Markus Armbruster <armbru@redhat.com>]

Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> writes:

> On 20.10.25 19:03, Vladimir Sementsov-Ogievskiy wrote:
>> Recently we moved to returning errp. Why to keep int return value?
>> Generally it doesn't help: you can't use in a logic of handling
>> an error, as you are never sure, that in future the logic in
>> the stack will not change: it may start to return another error
>> code in the same case, or return same error code in another case.
>> Actually, we can only rely on concrete errno code when get it
>> _directly_ from documented library function or syscall. This way we
>> handle for example EINTR. But later in a stack, we can only add
>> this errno to the textual error by strerror().
>> Let this new, recently added API be simpler and clearer, let it
>> return simple boolean value, so we shouldn't think:
>>    - should we handle different error codes differently
>>      (if yes - how exactly, if no - why do we need this information?)
>>    - should we add it to errp, or it was already added earlier in
>>      the stack
>
>
> Less aggressive commit message may be:
>
> Switch the new API to simple bool-returning interface, as return value
> is not used otherwise than check is function failed or not. No logic
> depend on concrete errno values.

Good, except it isn't quite accurate: callers include the return value
in error messages.

They format it as a number, which is inappropriate.

If they formatted it appropriately, with strerror(), would that be
helpful?  I *think* the answer is no.  The functions set an Error, and
their callers prepend to that Error's message.  The original Error
should suffice to tell what went wrong.  The prepended text's purpose is
to add context.

I think the easiest way to make this argument is to split this patch
into a part changing the error messages, and a part changing the return
type.