[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen: superficial clean-ups
On 6/11/19 18:29, Juergen Gross wrote: On 11.06.19 12:27, Andrew Cooper wrote:On 11/06/2019 11:25, Juergen Gross wrote:On 11.06.19 12:18, George Dunlap wrote:On 6/11/19 10:20 AM, Baodong Chen wrote:* Remove redundant set 'DOMDYING_dead' domain_create() will set this when fail, thus no need set in arch_domain_create(). * Set error when really happeneddiff --git a/xen/common/schedule.c b/xen/common/schedule.c index 86341bc..d6cdcf8 100644 --- 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'd rather switch to PTR_ERR() here dropping the perr parameter.+2 for this, but I was going to wait until core scheduling had gotten a bit further before suggesting cleanup which is guaranteed to collide. Sadly, it's fairly intrusive in the cpupool code as well.I can add this to my list of scheduler cleanups to do. Copy that. Juergen . _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |