qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] qemu-sockets: Fix assertion failure


From: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH] qemu-sockets: Fix assertion failure
Date: Wed, 20 Mar 2013 09:52:43 -0400

On Wed, 20 Mar 2013 14:37:59 +0100
Kevin Wolf <address@hidden> wrote:

> Am 20.03.2013 um 13:57 hat Luiz Capitulino geschrieben:
> > On Wed, 20 Mar 2013 09:39:34 +0100
> > Kevin Wolf <address@hidden> wrote:
> > 
> > > Am 19.03.2013 um 21:34 hat Luiz Capitulino geschrieben:
> > > > inet_connect_addr() has two users: inet_connect_opts() and 
> > > > wait_for_connect(),
> > > > with this patch both of them are now ignoring errors from 
> > > > inet_connect_addr().
> > > > 
> > > > Suggested solution: refactor inet_connect_addr() to return an errno 
> > > > value.
> > > > Callers use error_set() when they want to report an error upward.
> > > 
> > > Doesn't change the problem that you need to know when to set a return
> > > value != 0. So it doesn't help, but you'd lose some error information.
> > 
> > My real point is that it's easier to check against errno to find out
> > the error cause (compared to using Error for that).
> 
> You mean if the caller has to distinguish between different error codes?

Yes.

> I think I would agree that avoiding Error can be a good way then if it
> doesn't lose error information. If we would lose information, using
> error classes other than generic would be acceptable, right?

Yes, I think so.

I mean, even to me it's not entirely clear when new classes should be added.
The rule I had in mind was that a new class should be added when a QMP
client needs to distinguish a specific error. However, we're considering
QEMU subsystems to be QMP clients, which (taken to an extreme) would lead us
to our recent past where Error was trying to replace errno.

Markus once wrote about where to set boundaries between errno and Error, but I
don't remember if it was a private discussion or an email to the list. It's
time to write this down in docs/.



reply via email to

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