Re: [Xen-devel] [PATCH] xen: superficial clean-ups

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Tue, 2019-06-11 at 12:25 +0200, Juergen Gross wrote:
> On 11.06.19 12:18, George Dunlap wrote:
> > On 6/11/19 10:20 AM, Baodong Chen wrote:
> > > --- a/xen/common/schedule.c
> > > +++ b/xen/common/schedule.c
> > > @@ -1894,9 +1894,11 @@ struct scheduler *scheduler_alloc(unsigned
> > > int sched_id, int *perr)
> > >       return NULL;
> > >   
> > >    found:
> > > -    *perr = -ENOMEM;
> > >       if ( (sched = xmalloc(struct scheduler)) == NULL )
> > > +    {
> > > +        *perr = -ENOMEM;
> > >           return NULL;
> > > +    }
> > >       memcpy(sched, schedulers[i], sizeof(*sched));
> > >       if ( (*perr = SCHED_OP(sched, init)) != 0 )
> > 
> > I was going to say, this is a common idiom in the Xen code, and the
> > compiler will end up re-organizing things such that the write
> > doesn't
> > happen anyway.  But in this case, its' actually writing through a
> > pointer before and after a function call; I don't think the
> > compiler
> > would actually be allowed to optimize this write away.
> > 
> > So, I guess I'd be OK with this particular hunk.  Dario, any
> > opinions?
> 
I'm ok with it too, but...

> I'd rather switch to PTR_ERR() here dropping the perr parameter.
> 
... I'd be even more ok with this! :-)

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel