linux-kernel - Re: BFS v0.311 CPU scheduler for 2.6.32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 12 Dec 2009 13:00:54 +1100
From:	Con Kolivas <kernel@...ivas.org>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: BFS v0.311 CPU scheduler for 2.6.32

On Sat, 12 Dec 2009 11:55:39 Bartlomiej Zolnierkiewicz wrote:
> On Friday 11 December 2009 11:37:42 pm Con Kolivas wrote:
> > On Sat, 12 Dec 2009 02:12:58 Christoph Lameter wrote:
> > > On Sat, 12 Dec 2009, Con Kolivas wrote:
> > > > On Sat, 12 Dec 2009 01:10:39 Christoph Lameter wrote:
> > > > > Could you make the scheduler build time configurable instead of
> > > > > replacing the existing one? Embedded folks in particular may love a
> > > > > low footprint scheduler.
> > > >
> > > > It's not a bad idea, but the kernel still needs to be patched either
> > > > way. To get BFS they'd need to patch the kernel. If they didn't want
> > > > BFS, they wouldn't patch it in the first place.
> > >
> > > BFS would have a chance to be merged as an alternate scheduler for
> > > specialized situations (such as embedded or desktop use).
> >
> > Nice idea, but regardless of who else might want that, the mainline
> 
> FWIW I would also love to see it happen.

Thanks!

> > maintainers have already made it clear they do not.
> 
> Oh, those upstream bastards.. ;)
> 
> Why do you care so much about their acknowledgment?

Whaa...?

> 
> 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?

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