[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/3] tools: sched: add support for 'null' scheduler
On Mon, 2017-03-27 at 11:50 +0100, George Dunlap wrote: > On 17/03/17 18:43, Dario Faggioli wrote: > > --- a/tools/libxl/libxl_sched.c > > +++ b/tools/libxl/libxl_sched.c > > @@ -178,6 +178,20 @@ static int sched_arinc653_domain_set(libxl__gc > > *gc, uint32_t domid, > > return 0; > > } > > > > +static int sched_null_domain_set(libxl__gc *gc, uint32_t domid, > > + const libxl_domain_sched_params > > *scinfo) > > +{ > > + /* The null scheduler doesn't take any domain-specific > > parameters. */ > > + return 0; > > +} > > + > > +static int sched_null_domain_get(libxl__gc *gc, uint32_t domid, > > + libxl_domain_sched_params *scinfo) > > +{ > > + /* The null scheduler doesn't have any domain-specific > > parameters. */ > > + return ERROR_INVAL; > > +} > > Why the different return value? Why not return either INVAL or > SUCCESS > for both? > Because domain_set() is called by libxl_domain_sched_params_set(), which is in turn called unconditionally within libxl__build_post(), with the purpose of setting the scheduling parameters chosen by the user during domain creation. If that fails (I've tried that), domain creation fails too. So either it returns success, or we'd have to modify (at least) liblx__build_post(), teaching it about acceptable failures. OTOH, we indeed could return success for domain_get() too, for the sake of having the two above functions return the same. But I really think that call should fail, as an indication to the callers that they won't get the value of any parameter for this scheduler. The behavior achieved by this patch is the same one already in place for ARINC653, with the difference that sched_arinc653_sched_get() is not implemented, which means it is libxl_domain_sched_params_get() that fails, if LIBXL_SCHED_ARINC653 is used. That's an option too, but then libxl will also print "Unknown scheduler", which is not really correct (not even in the ARINC case, actually!). So, having evaluated all the choices, the asymmetric behavior above seems the best one to me. And I'll add a comment to explain the situation. Thanks and regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |