Re: [PATCH 4/5] sched/arinc653: Reorganize function definition order

[Jeff Kubascik <jeff.kubascik@xxxxxxxxxxxxxxx>]

On 9/17/2020 10:17 AM, Andrew Cooper wrote:
> On 17/09/2020 09:12, Jan Beulich wrote:
>> On 16.09.2020 20:18, Jeff Kubascik wrote:
>>> @@ -517,27 +516,35 @@ static const struct scheduler sched_arinc653_def = {
>>>      .sched_id       = XEN_SCHEDULER_ARINC653,
>>>      .sched_data     = NULL,
>>>
>>> +    .global_init    = NULL,
>>>      .init           = a653sched_init,
>>>      .deinit         = a653sched_deinit,
>>>
>>> -    .free_udata     = a653sched_free_udata,
>>> -    .alloc_udata    = a653sched_alloc_udata,
>>> +    .alloc_pdata    = NULL,
>>> +    .switch_sched   = a653sched_switch_sched,
>>> +    .deinit_pdata   = NULL,
>>> +    .free_pdata     = NULL,
>>>
>>> +    .alloc_domdata  = NULL,
>>> +    .free_domdata   = NULL,
>>> +
>>> +    .alloc_udata    = a653sched_alloc_udata,
>>>      .insert_unit    = NULL,
>>>      .remove_unit    = NULL,
>>> +    .free_udata     = a653sched_free_udata,
>>>
>>>      .sleep          = a653sched_unit_sleep,
>>>      .wake           = a653sched_unit_wake,
>>>      .yield          = NULL,
>>>      .context_saved  = NULL,
>>>
>>> -    .do_schedule    = a653sched_do_schedule,
>>> -
>>>      .pick_resource  = a653sched_pick_resource,
>>> +    .migrate        = NULL,
>>>
>>> -    .switch_sched   = a653sched_switch_sched,
>>> +    .do_schedule    = a653sched_do_schedule,
>>>
>>>      .adjust         = NULL,
>>> +    .adjust_affinity= NULL,
>> Adding all these not really needed NULL initializers looks to rather move
>> this scheduler away from all the others. (Oddly enough all of them
>> explicitly set .sched_data to NULL - for whatever reason.)
> 
> The "= NULL" is totally redundant, because the compiler will do that for
> you.

I agree with this. This originally was intended to lay the groundwork for patch
#5, but looking at it again, was confusing and unnecessary. I'll remove the =
NULL lines.

> The last user of .sched_data was dropped by 9c95227160.  Conceptually,
> it is a layering violation (it prevents different cpupools being
> properly independent), so I'd recommend just dropping the field entirely.

I'll remove .sched_data above.

-Jeff