[LITMUS^RT] suggestion on reservation_config

Björn Brandenburg bbb at mpi-sws.org
Thu Nov 6 20:04:51 CET 2014


On 06 Nov 2014, at 17:15, gokul vasan <gokulvas at gmail.com> wrote:
> we are trying to implement Slot shiting algorithm on reservation framework.
> 
> I see the the struct reservation_config has a union which specifies the specific parameters of particular reservation ( currently polling_params, table_driven), but I presume this would soon become  unreadable when many other specific reservation arises( like in my case slot_shifting ).
>  would  it be better to hold a dynamic array of char, which we can typecast to the specific structure once we receive at kernel space? 
> 
> current implementation : 
> 
> struct reservation_config {
>         unsigned int id;
>         lt_t priority;
>         int  cpu;
> 
>         union {
>                 struct {
>                         lt_t period;
>                         lt_t budget;
>                         lt_t relative_deadline;
>                         lt_t offset;
>                 } polling_params;
> 
>                 struct {
>                         lt_t major_cycle_length;
>                         unsigned int num_intervals;
>                         struct lt_interval __user *intervals;
>                 } table_driven_params;
>         };
> }
> 
> received by static long pres_reservation_create(int res_type, void* __user _config)
> 
> Suggested implementation: 
> 
> struct reservation_config {
>         unsigned int id;
>         lt_t priority;
>         int  cpu;
>         unsigned char data[0]; // dynamic array which holds the reservation specific data.
>   }
> 
> struct res_type {
>        int type;
>         int length; // holds the length of the struct reservation_config.
> };
> 
> static long pres_reservation_create(struct res_type, void* __user_config)
> 
> just a suggestion for maintaining  generic reservation framework.

Yes, that would be preferable. However, the reservation framework hasn't been merged yet, and in the prototype we have only a small number of types. 

In any case, I would be happy to merge such a patch.

- Björn





More information about the litmus-dev mailing list