[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 remain. 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 |