Messages in this thread | | | Date | Tue, 12 Nov 2013 12:23:45 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH 02/14] sched: add extended scheduling interface. |
| |
On Thu, 7 Nov 2013 14:43:36 +0100 Juri Lelli <juri.lelli@gmail.com> wrote:
> + * This is reflected by the actual fields of the sched_param2 structure: > + * > + * @sched_priority task's priority (might still be useful) > + * @sched_deadline representative of the task's deadline > + * @sched_runtime representative of the task's runtime > + * @sched_period representative of the task's period > + * @sched_flags for customizing the scheduler behaviour > + * > + * Given this task model, there are a multiplicity of scheduling algorithms > + * and policies, that can be used to ensure all the tasks will make their > + * timing constraints. > + * > + * @__unused padding to allow future expansion without ABI issues > + */ > +struct sched_param2 { > + int sched_priority; > + unsigned int sched_flags;
I'm just thinking, if we are creating a new structure, and this structure already contains u64 elements, why not make sched_flags u64 too? We are now just limiting the total number of possible flags to 32. I'm not sure how many flags will be needed in the future, maybe 32 is good enough, but just something to think about.
Of course you can argue that the int sched_flags matches the int sched_priority leaving out any holes in the structure, which is a legitimate argument.
> + u64 sched_runtime; > + u64 sched_deadline; > + u64 sched_period; > + > + u64 __unused[12];
And in the future, we could use one of these __unused[12] as a sched_flags2;
I'm not saying we should make it u64, just wanted to make sure we are fine with it as 32 for now.
-- Steve
> +}; > +
| |