William Lee Irwin III wrote: >> Last I checked there were limits to runtime configurability centering >> around only supporting a compiled-in set of scheduling drivers, unless >> Peter's taken it the rest of the way without my noticing. It's unclear >> what you have in mind in terms of dynamic extensibility. My only guess >> would be pluggable scheduling policy/class support for individual >> schedulers in addition to plugging the individual schedulers, except >> I'm rather certain that Williams' code doesn't do anything with modules.
On Sat, Mar 10, 2007 at 07:47:11PM +0300, Al Boldi wrote: > Correct, it doesn't, yet. But do you think that PlugSched has the basic > infrastructure in place to support this, or would it require a complete > redesign/rewrite. The piece I got done was just representing schedulers as driver-like affairs (which, embarrassingly enough, needed lots of bugfixing), and everyone's just been running with that and boot-time switching ever since. Runtime switching (to module-loaded schedulers or otherwise) needs a lot of hotplug-esque work. Scheduler class support, pluggable or otherwise, needs per-scheduler abstracting things out along the same lines as what was originally done for the overall schedulers surrounding enqueueing and dequeueing so the scheduler itself only plucks tasks out of and stuffs tasks into some sort of abstracted-out queue or set of queues, though I did try to break things down at a low enough level where they'd be plausible for more than just the one driver (never distributed) I used to test the design. I dumped the entire project long before ever getting to where modules entered the picture, and have never touched modules otherwise, so I'm not entirely sure what other issues would come up with those after the smoke clears from runtime switching. I don't plan on doing anything here myself, since the boot-time switching etc. is likely already considered offensive enough. The next time something comes up that bears a risk of positioning me against the kernel's political winds, I'll just rm it or not write it at all instead of leaving code around (or worse yet, passing it around) to be taken up by others. It just leaves a lot of embarrassed explaining to do when it resurfaces years later, or otherwise leaves a rather bad taste in my mouth when NIH'd years later like other things not mentioned here (VM code kept quiet similarly to plugsched) and everyone approves so long as it didn't come from me. -- wli - 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/
