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

Re: [Xen-devel] [PATCH v5 3/9] ioreq-server: centralize access to ioreq structures



>>> On 06.05.14 at 16:32, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >>> On 06.05.14 at 16:13, <Paul.Durrant@xxxxxxxxxx> wrote:
>> >> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> > >>> On 01.05.14 at 14:08, <paul.durrant@xxxxxxxxxx> wrote:
>> >> > > --- a/xen/arch/x86/hvm/hvm.c
>> >> > > +++ b/xen/arch/x86/hvm/hvm.c
>> >> > > @@ -363,6 +363,26 @@ void hvm_migrate_pirqs(struct vcpu *v)
>> >> > >      spin_unlock(&d->event_lock);
>> >> > >  }
>> >> > >
>> >> > > +static ioreq_t *get_ioreq(struct vcpu *v)
>> >> >
>> >> > const struct vcpu *? Or was it that this conflicts with a subsequent
>> >> > patch?
>> >> >
>> >>
>> >> I guess that could be done, although it wasn't const before it was moved.
>> >>
>> >
>> > Attempting this causes issues when using vcpu_runnable() in a subsequent
>> > patch, so I won't do it.
>> 
>> Just make vcpu_runnable()'s parameter const too then - it easily can
>> be.
> 
> That causes the build to fail because atomic_read() discards the const 
> qualifier.

I guess just leave it then, albeit I'm tempted to ask to also fix that
one in turn. I'm of the opinion that we really ought to make much
broader use of const, especially to document functions not intended
to alter state.

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