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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

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?

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
Description: This is a digitally signed message part

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