Re: [Xen-devel] [PATCH 3/3] tools: sched: add support for 'null' scheduler

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Apr 06, 2017 at 05:18:33PM +0200, Dario Faggioli wrote:
> On Thu, 2017-04-06 at 14:59 +0100, George Dunlap wrote:
> > On 06/04/17 11:49, Dario Faggioli wrote:
> > > 
> > > 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.
> > 
> > I see.  So if *our* code doesn't know that there aren't any
> > parameters
> > to set, that's OK; but if *other people's code doesn't know that
> > there
> > aren't any parameters to get, it needs to be changed to know
> > that.  Got
> > it. ;-)
> > 
> Of course! I mean, there must be some advantages and benefits in being
> *us*! :-D
> 
> Actually, jokes apart, this is indeed asymmetric, but looks fair to me.
> As in, _any_ caller (either xl/libxl or external) will see
> libxl_domain_sched_params_set() succeeding, as well as _any_ caller
> (either xl/libxl or external) will see libxl_domain_sched_params_get()
> failing. :-)
> 
> > There is a sort of mathematical logic to the idea that setting a null
> > set of parameters should always succeed; and it's certainly
> > convenient
> > for tools to be able to always just call
> > libxl_domain_sched_params_set()
> > without having to check what scheduler is there.  But the same logic
> > I
> > think applies to get(), so I would say to return 0 for both.
> > 
> I understand your point, and I'm happy to do that.
> 
> > But Wei and Ian have the final say.
> > 
> Wei acked this patch in v1 (20170321170902.ndk6h5ylyfkk4coo@xxxxxxxxxx)
> but that was before you raised this, so I'm happy to resend with this
> changed, and doing whatever he prefers with his ack.
> 
> Wei?

I don't feel strongly about this. But if you want to return success in
the get function, please make sure you initialise output to a known
state, instead of returning random garbage.

Wei.

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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel