Messages in this thread | | | Date | Wed, 13 Nov 2013 09:43:01 +0100 | From | Juri Lelli <> | Subject | Re: [PATCH 02/14] sched: add extended scheduling interface. |
| |
On 11/12/2013 06:23 PM, Steven Rostedt wrote: > 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. >
I'd stick with the current declaration for exactly the points you have made.
What others think?
Thanks,
- Juri
| |