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]
Message-ID: <alpine.LFD.1.10.0805060258360.3318@apollo.tec.linutronix.de>
Date:	Tue, 6 May 2008 03:30:46 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Daniel Walker <dwalker@...sta.com>
cc:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
	Sven-Thorsten Dietrich <sven@...bigcorporation.com>,
	Remy Bohmer <linux@...mer.net>,
	LKML <linux-kernel@...r.kernel.org>,
	RT <linux-rt-users@...r.kernel.org>,
	Jon Masters <jonathan@...masters.org>
Subject: Re: Preempt-RT patch for 2.6.25

On Mon, 5 May 2008, Daniel Walker wrote:
> On Tue, 2008-05-06 at 01:47 +0200, Ingo Molnar wrote:
> > * Daniel Walker <dwalker@...sta.com> wrote:
> > 
> > > I think dropping ports (temporarily) is perfectly reasonable. There is 
> > > no reason to hamper forward development just to keep old architecture 
> > > ports in the tree.
> > 
> > You are missing the point: a lot of people (those who wrote the brunt of 
> > the -rt tree and who maintained it over the years and who maintain it 
> > today) think it's not reasonable and have stated it very clearly to you 
> > that it's a bug. Keeping things alive is not preventing forward 
> > development.
> 
> That has always been my intention. I've never said the arch code would
> be permanently gone. 

Get it. Dropping it means bitrot.

The responsible maintainers keep that (maybe stale) code at least in
sync as far as the obvious fixups are concerned.

Your way of chosing the least effort approach and justifying it with
handwaving arguments is just disgusting.
 
> > Since it's code that you regard stale it shouldnt be all that hard to 
> > fix it up - in general it's much easier to fix a bug than to talk it out 
> > of existence, even if you disagree with a maintainer about how 
> > significant a bug is.
> 
> It shouldn't be hard, but it's too much to do all in one go. It's better
> from my perspective to do it in parts, given that there is significant
> refactoring to do per arch, if we solidify x86 then we can better
> refactor the other architectures. Better to do the split up once vs.
> many times.

Ah, it's too much in one go. But we should accept an "all in one go"
refactoring of the code we maintained over years including your
decision to drop fully functional ports (FYI, I've verified it) just
because you define that it's the best way to go.

Again, there is a choice.

1) Work with us - the maintainers and major contributors to preempt-rt -
   in a way which is useful for the project and the community

2) Hold on to your private "superior" uber queue and STFU.

> Not to mention this has not been discussed until now. My bisect tree was
> all but ignored until just recently.

It will be ignored for ever until you decide to work with us instead
of requesting that we drop our work in favour of your incomplete and
buggy hackery.

> > This issue is clearly not central to your refactoring (it cannot be, 
> > it's all about stale code), so by inflexibly insisting on your opinion 
> > against the (well-explained) opinion of the maintainers you'll just 
> > waste their time and make it more difficult for them to work with you, 
> > for no good reason.
> 
> I'm simply making sure their argument is widely known and potentially
> discussed on list instead of in a back room..

I'm impressed by your selfless efforts to save the world from the
ongoing preempt-rt conspiracy.

Thanks,

	tglx
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ