[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


 


Rackspace

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