Re: [Xen-devel] [PATCH v5 4/9] ioreq-server: create basic ioreq server abstraction.

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 06 May 2014 14:51
> To: Paul Durrant
> Cc: xen-devel@xxxxxxxxxxxxx; Keir (Xen.org)
> Subject: RE: [PATCH v5 4/9] ioreq-server: create basic ioreq server
> abstraction.
> 
> >>> On 06.05.14 at 15:44, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Paul Durrant
> >> > >> > +static int hvm_replace_event_channel(struct vcpu *v, domid_t
> >> > >> remote_domid,
> >> > >> > +                                     evtchn_port_t *p_port)
> >> > >> > +{
> >> > >> > +    evtchn_port_t old_port, new_port;
> >> > >> > +
> >> > >> > +    new_port = alloc_unbound_xen_event_channel(v,
> >> remote_domid,
> >> > NULL);
> >> > >> > +    if ( new_port < 0 )
> >> > >> > +        return new_port;
> >> > >>
> >> > >> I'm pretty sure I commented on this too in a previous version:
> >> > >> evtchn_port_t is an unsigned type, hence checking it to be negative
> >> > >> is pointless.
> >> > >
> >> > > Yes, but as I'm pretty sure I responded,
> >> > alloc_unbound_xen_event_channel()
> >> > > doesn't return an evtchn_port_t!
> >> >
> >> > Which doesn't matter here at all: Once you store the function result
> >> > in a variable of type evtchn_port_t, its original signedness is lost.
> >> >
> >>
> >> ...which is probably why I had these coded as unsigned longs originally. 
> >> I'll
> >> change them back.
> >
> > ... and of course, I mean longs there and not unsigned longs!
> 
> In which case you ought to mean int, as that's what the function
> returns. No need for widening that value.
>

Ok. Good point.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel