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

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


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Tue, 6 May 2014 13:53:03 +0000
  • Accept-language: en-GB, en-US
  • Cc: "Keir \(Xen.org\)" <keir@xxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Tue, 06 May 2014 13:53:12 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AQHPZTYbJXXdY1DBjUu9mL7T/Yi8xJszaNQAgAAj3wD//+RegIAAJRxwgAAB4YD//+CIAIAAIePQ
  • Thread-topic: [PATCH v5 4/9] ioreq-server: create basic ioreq server abstraction.

> -----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


 


Rackspace

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