Peter Williams wrote:

>They shouldn't interfere as which scheduler to use is a boot time 
>selection and only one scheduler is in force.  It's mainly a coding 
>matter and in particular whether the "scheduler driver" interface would 
>need to be modified or whether your scheduler can be implemented using 
>the current interface.
>  
>

Yes, that's the key issue I think - the interface now has more inputs.

>>I guess the big question is - is there a corresponding concept in
>>> PlugSched?  for instance, is there a reference in the task_struct to the
>>> current scheduling domain, or is it more CKRM-style with classification
>>> modules?
>>    
>>
> It uses the standard run queue structure with per scheduler
> modifications (via a union) to handle the different ways that the
> schedulers manage priority arrays (so yes). As I said it restricts
> itself to scheduling matters within each run queue and leaves the
> wider aspects to the normal code.


Ok, so there is no existing "classification" abstraction?  The
classification is tied to the scheduler implementation?

>At first guess, it sounds like adding your scheduler could be as simple 
>as taking a copy of ingosched.c (which is the implementation of the 
>standard scheduler within PlugSched) and then making your modifications. 
>  You could probably even share the same run queue components but 
>there's nothing to stop you adding new ones.
>
>Each scheduler can also have its own per task data via a union in the 
>task struct.
>  
>

Ok, sounds like that problem is solved - just the classification one
remaining.

>OK.  I'm waiting for the next -mm kernel before I make the next release.
>  
>

Looking forward to it.

>>Now, forgive me if I'm preaching to the vicar here, but have you tried
>>using Stacked Git for the patch development?
>>    
>>
>
>No, I actually use the gquilt GUI wrapper for quilt 
><http://freshmeat.net/projects/gquilt/> and, although I've modified it 
>to use a generic interface to the underlying patch management system 
>(a.k.a. back end), I haven't yet modified it to use Stacked GIT as a 
>back end.  I have thought about it and it was the primary motivation for 
>adding the generic interface but I ran out of enthusiasm.
>  
>

Hmm, guess the vicar disclaimer was a good one to make.

Well maybe you'll find the attached file motivating, then.

Sam.