qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael R. Hines
Subject: Re: [Qemu-devel] [PULL v4 08/11] rdma: core logic
Date: Thu, 18 Apr 2013 15:41:30 -0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]