| |||||||||||||
Deadline scheduling for LinuxDeadline scheduling for LinuxPosted Oct 13, 2009 17:11 UTC (Tue) by nix (subscriber, #2304)Parent article: Deadline scheduling for Linux
sched_setscheduler_ex()? What is it with people and really bad syscall names lately? If this really is specific to deadline parameters, sched_setscheduler_deadline() would surely be a better name.
(Log in to post comments)
Deadline scheduling for Linux Posted Oct 13, 2009 22:37 UTC (Tue) by vieuxtech@gmail.com (guest, #54592) [Link]
It's not clear why there needs to be a new syscall. sched_setscheduler() already exists, and it's struct sched_param argument can be extended to include parameters specific to particular scheduler policies.
Deadline scheduling for Linux Posted Oct 14, 2009 10:26 UTC (Wed) by raistlin (guest, #37586) [Link]
Well, extending struct sched_param is more than possible, I agree, but it would be a _really_big_ ABI issue, don't you think?
Especially when a 'legacy' binary comes to, e.g., a sched_getparam, and the data it gets will be bigger than expected... :-(
Regards,
Deadline scheduling for Linux Posted Oct 14, 2009 21:10 UTC (Wed) by quotemstr (subscriber, #45331) [Link] but it would be a _really_big_ ABI issue, don't you think?I was about to write about how that's not the case, but you're right: whose bright idea was it to have sched_getscheduler not take a length parameter like getpeername does?
Deadline scheduling for Linux Posted Oct 14, 2009 10:34 UTC (Wed) by raistlin (guest, #37586) [Link]
:-D
Actually, good point!
In our intents _ex stands for EXtended, which means it can be used not only for this particular new scheduling policy, but for all the ones (if/when they will come! :-P) that needs the EXtended sched_param structure.
(It is the same name used by Xenomai for the same purpose, i.e., supporting new scheduling policies with extended parameters, such as POSIX's SCHED_SPORADIC.)
I think it _is_ a good thing to keep this general but, hey, we can discusss about that! :-)
Regards,
Deadline scheduling for Linux Posted Oct 14, 2009 16:32 UTC (Wed) by nix (subscriber, #2304) [Link]
OK (though the name is reminiscent of the horrible Win32 API to my ears), but adding a new scheduler requiring different parameters would be another ABI change, wouldn't it, requiring another new syscall: the parameter type would change. Either that or you make the parameter type a void *, which is just ioctl() in new clothes and Linus would tear your lungs out.
Or something like that.
Deadline scheduling for Linux Posted Oct 14, 2009 22:15 UTC (Wed) by raistlin (guest, #37586) [Link]
Well, this may be true or not, depending on the new new scheduler!
Generally speacking, you are definitely right, since each new scheduler/scheduling class could ask some room for its own parameter(s).
However, I'm sure that, if things keep going, this issue will came up in LKML at some point, and then we we'll see what people there think... :-D
Thanks for your comments,
Deadline scheduling for Linux Posted Oct 14, 2009 21:13 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
When you created the _ex functions, why didn't you make them take length parameters like the socket-address ones do, thus solving the ABI compatibility problem once and for all?
Deadline scheduling for Linux Posted Oct 15, 2009 5:29 UTC (Thu) by raistlin (guest, #37586) [Link]
Very, very nice idea!
/me more than considering that! :-D
Thanks,
Deadline scheduling for Linux Posted Oct 22, 2009 10:05 UTC (Thu) by cesarb (subscriber, #6266) [Link]
This ..._ex() naming is really horrible. What do you do when you need to extend it again? Call it ..._ex2()? ..._ex_ex()?
Unix solved that naming problem in a much more elegant way a long time ago, by simply appending the number of parameters. So we have wait3() and wait4(); dup(), dup2(), and the new dup3(); pipe() and pipe2(); inotify_init() and inotify_init1(); and so on (see http://udrepper.livejournal.com/20407.html for how recent some of these are).
|
|||||||||||||