linux-kernel - Re: Preempt-RT patch for 2.6.25

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:	Tue, 6 May 2008 12:32:00 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Daniel Walker <dwalker@...sta.com>
cc:	Thomas Gleixner <tglx@...utronix.de>,
	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>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: Preempt-RT patch for 2.6.25

On Tue, 6 May 2008, Daniel Walker wrote:
>
> As I've been saying, had you wanted the architectures included, you
> should have said that a month ago. You had a month you review everything
> and work with me ..

Daniel,

Don't give me this "wo is me" crap.  After you posted the series I replied
asking that you prove that it doesn't do any changes to the actual code.

http://marc.info/?l=linux-kernel&m=120761484315539&w=2

But you admit that you didn't do that yourself. This is also the time that
we were very busy at working on ftrace and hoping it would make it into
2.6.26 (which it did not). Remember our goal is to get as much as possible
into mainline Linux. And getting something from -rt (ftrace) into Linux
was the higher priority for me than to go review your series after you
tell me that you dropped archs and made changes to the code for the sake
of bisectability.

I thought my response was good enough to give you a clue that you needed
to show that your work didn't make any changes. Making the tree bisectable
is a "clean up" not a code design. And with all clean ups, they should not
cause any changes to code behaviour. You've been doing kernel development
long enough to know this. I'm not about to hold your hand and step you
through the proper process of getting things accepted.

If you don't make an effort to work with the maintainers instead of just
shoving out a bunch of code and expect us to do the dirty work to make
sure its ok, then you might as well give up. Take a lesson from Gregory
Haskins. He came out with a lot of changes that were controversial at the
time. Instead of shoving his code down our throats, he took our critisms
seriously and worked hard to work with us. Now most of his code, even the
controversial parts, has been incorporated.

-- Steve

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