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

Re: [Xen-devel] [PATCH 24/29] libvchan: handle libxc evtchn failures properly in init functions

On Thu, Oct 31, 2013 at 3:52 AM, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> On 10/30/2013 06:12 AM, Matthew Daley wrote:
>> On Wed, Oct 30, 2013 at 8:52 PM, Matthew Daley <mattjd@xxxxxxxxx> wrote:
>>> Also, remove now-unnecessary check from close function.
>>> Coverity-ID: 1055609
>>> Coverity-ID: 1055610
>>> Coverity-ID: 1055611
>>> Signed-off-by: Matthew Daley <mattjd@xxxxxxxxx>
>> I should clarify: the base reason for this patch is that
>> ctrl->event_port is a uint32_t (ie. unsigned), so the current checks
>> on it for negative error results, non-negative port presence etc. are
>> incorrect.
>> I can spin a v2 with this mentioned if desired.
>> - Matthew
> I agree the clarification would be useful in the commit message. If you're
> spinning a v2, you may want to use evtchn_port_or_error_t in place of int
> since that is the actual typedef used in the return.

Hmm, OK. I was thinking that it may not make sense to carry a
evtchn_port_or_error_t type outside of the init functions and into the
library's state (where it could be assumed that if there is a valid
evtchn xc handle, there is a valid port too), but I suppose it
simplifies the code, and allows that check in the close function to

v2 on its way...

- Matthew

> Either way,
> Reviewed-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.