Re: [Xen-devel] [PATCH 4/6] xen/sched: Remove {init, destroy}_domain() interfaces

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 02/28/2018 02:14 PM, Andrew Cooper wrote:
> These hooks have one single caller (sched_{init,destroy}_domain()
> respectively) and are all identical (when implemented).
> 
> Previous changes have ensured that only real domains reach these functions, so
> ASSERT() that system domains are not seen. Call sched_{alloc,free}_domdata()
> directly, and handle d->sched_priv directly.
> 
> The net diffstat is:
>   add/remove: 0/8 grow/shrink: 1/7 up/down: 7/-335 (-328)
>   function                                     old     new   delta
>   sched_destroy_domain                         130     137      +7
>   sched_init_domain                            138     137      -1
>   rt_dom_destroy                                 6       -      -6
>   null_dom_destroy                               6       -      -6
>   csched_dom_destroy                             9       -      -9
>   csched2_dom_destroy                            9       -      -9
>   sched_rtds_def                               264     248     -16
>   sched_null_def                               264     248     -16
>   sched_credit_def                             264     248     -16
>   sched_credit2_def                            264     248     -16
>   sched_arinc653_def                           264     248     -16
>   ops                                          264     248     -16
>   rt_dom_init                                   52       -     -52
>   null_dom_init                                 52       -     -52
>   csched_dom_init                               52       -     -52
>   csched2_dom_init                              52       -     -52
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

I kind of feel like there was a reason for the init / alloc difference;
but as you say, at the moment all the schedulers are basically
identical.  In the unlikely event that we need separate callbacks, we
can introduce them at such time as we have a need for them.

Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>

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