Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Deadline scheduling for Linux
Posted Oct 13, 2009 22:37 UTC (Tue) by email@example.com (guest, #54592)
Posted Oct 14, 2009 10:26 UTC (Wed) by raistlin (guest, #37586)
Posted Oct 14, 2009 21:10 UTC (Wed) by quotemstr (subscriber, #45331)
but it would be a _really_big_ ABI issue, don't you think?
Posted Oct 14, 2009 10:34 UTC (Wed) by raistlin (guest, #37586)
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! :-)
Posted Oct 14, 2009 16:32 UTC (Wed) by nix (subscriber, #2304)
Or something like that.
Posted Oct 14, 2009 22:15 UTC (Wed) by raistlin (guest, #37586)
Generally speacking, you are definitely right, since each new scheduler/scheduling class could ask some room for its own parameter(s).
What we were thinking here is (and this also comes from some comments/suggestions we got on LKML):
- if we define a general enough task model, it is likely that even new
algorithms can deal with that, without the need of their very specific
- if we want, sched_param_ex could be bloated a little bit with some
padding or non-utilized field, reserved for future extensions.
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,
Posted Oct 14, 2009 21:13 UTC (Wed) by quotemstr (subscriber, #45331)
Posted Oct 15, 2009 5:29 UTC (Thu) by raistlin (guest, #37586)
/me more than considering that! :-D
Posted Oct 22, 2009 10:05 UTC (Thu) by cesarb (subscriber, #6266)
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).
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds