Messages in this thread | | | Subject | Re: [RFC][PATCH 02/22] sched: add extended scheduling interface | From | Raistlin <> | Date | Thu, 11 Nov 2010 14:54:08 +0100 |
| |
On Thu, 2010-11-11 at 14:32 +0100, Peter Zijlstra wrote: > > BTW, as Dhaval was suggesting, are (after those changes) fine with this > > new sched_param? Do we need some further mechanism to grant its > > extendability? > > Padding? > > Versioning? > > void *data field? > > Whatever? > > > > :-O > > > > I'd like very much to have some discussion here, if you think it is > > needed, in hope of avoiding future ABI issues as much as possible! :-P > > Right, so you mentioned doing s/_ex/2/ on all this stuff, which brings > it more in line with that other syscalls have done. > Sure, this is necessary and easy to achieve. :-)
> The last three parameters look to be output only as I've not yet found > code that reads it, and __getparam_dl() doesn't even appear to set > used_runtime. > Yeah, just kind of statistical reporting of the task's behaviour. That's why I was in agreement with Dhaval about using schedstats for those (bumping the version, obviously). What do you think?
> One thing you can do is add some padding, versioning and void* > extentions are doable for the setparam() path, but getparam() is going > to be mighty interesting. > Mmm... So, tell me if I got it well: I remove the last three parameters (e.g., moving them toward schedstats) and add (besides _var and _max) some padding? It that correct?
what about the len <== sizeof(struct sched_param2) in sched_{set,get}{param,scheduler}2()... Does this still make sense, or are we removing it?
Thanks, Dario
-- <<This happens because I choose it to happen!>> (Raistlin Majere) ---------------------------------------------------------------------- Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)
http://blog.linux.it/raistlin / raistlin@ekiga.net / dario.faggioli@jabber.org [unhandled content-type:application/pgp-signature] | |