Re: BFS v0.311 CPU scheduler for 2.6.32

[Con Kolivas]

On Sat, 12 Dec 2009 16:54:59 Willy Tarreau wrote:
> Hi Con,
> 
> On Sat, Dec 12, 2009 at 01:00:54PM +1100, Con Kolivas wrote:
> > > If you are not doing your unpaid kernel work for yourself and for
> > > people who recognize/use it then upstream maintainers not liking your
> > > changes should really be the least of your worries..
> >
> > Wait, this does not make sense. There's a cyclical flaw in this
> > reasoning. If I cared about their acknowledgment, I would make it
> > mainline mergeable and argue a case for it, which I do not want to do.
> >
> > I'm happy to make reasonable changes to the code consistent with what
> > people who use it want, but what exactly is the point of making it
> > mainline mergeable if it will not be merged?
> 
> Many people build their own kernels by :
>   1) applying a lot of patches on them (stable + features)
>   2) using machine-specific configs
> 
> You will get far more testers if they can use the same kernel and
> just play with their config files than if they have to patch/unpatch
> depending on what they need to have.
> 
> I personally would love to be able to add BFS into my kernels for
> testing purposes, comparison, and possibly to propose enhancements
> and fixes. But I don't want to *replace* mainline code.
> 
> Also, I like to have the same kernel sources used on my desktop,
> notebook, eeepc, and my bootable USB key. It is a lot easier to
> upgrade and a lot easier to spot bugs before they strike in sensible
> environments.

Thanks Willy. 

That's the first meaningful reason I've heard for it. I may have to consider 
it now. It still would be compile time limited so probably not quite what 
you're hoping for. I don't have the time and energy to do and maintain the 
whole plugsched crap for boottime selection all over again, and that adds 
overhead which goes against one of my prime objectives.

Regards,
-- 
-ck
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/