Re: [Qemu-devel] [PULL v4 08/11] rdma: core logic

["Michael R. Hines" <mrhines@linux.vnet.ibm.com>]

On 04/18/2013 11:51 AM, Orit Wasserman wrote:
> On 04/18/2013 04:54 PM, Michael R. Hines wrote:
>> On 04/18/2013 04:44 AM, Orit Wasserman wrote:
>>> Hi Michael,
>>>
>>> I don't see you addressed any of the comment I had in v3
>>> (especially the error handling)
>>>
>>> please, fix those
>> I did fix them, but not all of your comments were correct,
>> because I was passing errp in many places were errp
>> did not supposed to belong there.
> If you decide not to fix some comment you just need
> to reply to the comment and explain the reason,
> this makes the reviewing process easier.
>

Ok, so here's a more specific question while I have your ears,
that is a problem I'm having with error_setg():

Currently, the migration works by calling "qemu_set_handler_fd2()",
which comes along and calls "accept_incoming_migration" on the
destination side.

The problem with this from an error-handling perspective is that
there is no global datastructure on the destination side, similar to
"MigrationState".

Thus, there is nowhere to propagate errors to, even if we want to
do so - and that's why I deleted most of the error_setg() comments
that you had because they were mostly focus on delivering an error
without having any part of the call stack to actually *process* the error.

So, without overly-complicating error propagation on the destination side,
what solution would you recommend for both TCP and RDMA?



>> So, first I *removed* errp from being proliferated all over
>> the entire file, which was not necessary.
>>
>> Then, in the places where errp is required by migration.c,
>> I added new uses of errp.
> That is fine as long as external rdma API use errp and the
> internal always return some error code.
>
> Also I noticed that the errors are very general for example
> in qemu_rdma_connect we set the same error always it will be more
> helpful to have different errors for each case. We need
> errors that can help the user to understand what went wrong.
>
> Orit
>> There are some places, as Paolo mentioned where errp was
>> written twice, which I must fix, however.
>>