On 11/12/2013 06:23 PM, Steven Rostedt wrote: > On Thu, 7 Nov 2013 14:43:36 +0100 > Juri Lelli <[email protected]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
