[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 11:07 AM, Matthew Daley <mattjd@xxxxxxxxx> wrote: > 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 > remain. Sorry, I missed the "int" in your reply. Yes, changing that type makes even more sense. > > v2 on its way... > > - Matthew > >> >> Either way, >> Reviewed-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> >> >> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |