From: Daniel Walker <dwalker@mvista.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Sven-Thorsten Dietrich <sven@thebigcorporation.com>,
Remy Bohmer <linux@bohmer.net>,
LKML <linux-kernel@vger.kernel.org>,
RT <linux-rt-users@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jon Masters <jonathan@jonmasters.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: Preempt-RT patch for 2.6.25
Date: Mon, 05 May 2008 10:04:44 -0700 [thread overview]
Message-ID: <1210007084.17132.32.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.58.0805051240520.25250@gandalf.stny.rr.com>
On Mon, 2008-05-05 at 12:44 -0400, Steven Rostedt wrote:
> On Mon, 5 May 2008, Daniel Walker wrote:
> >
> > You should review my tree, it is several steps closer to mainline that
> > the -rt version your working on. I did a lot of patch break-ups
> > (required for bisection, and makes for a cleaner tree) and re-arranging
> > patches.
>
> I may take a look at your tree. But as for the rt version I'm working on,
> is not the same as the one you started with. I did a lot of merging, I
> also have the new ftrace code in there. I also moved patches around to
> what we will be pushing to mainline.
That's really the point, you should have started with my version. I
released my changes long before the 2.6.25 release.
> >
> > Bisection is also required for mainline integration ..
>
> Bisection is required for each element, we don't need it for the entire
> tree (atm). If we waste our time making the entire tree fully bisectable,
> then it will be a lot of work to maintain that bisectability when we
> rewrite entire sections.
Bisection is required for everything, every patch. I am giving you a
bisect tree, there is no time wasted (only mine)..
I'm not following your logic Steven .. You want bisection , that means
you should want to maintain it, and write code in the future which also
bisects.
If someone submits code which doesn't bisect you kick it the same way
it's kicked from mainline. That means future patches in -rt are ready
for mainline which helps further the goal of mainline integration.
> I am making it boot with certain parts intergrated. But my goal is not to
> have every single patch compile and boot. We'll worry about that when we
> need to push a part of the code in. But reality, what is there now, I can
> guarantee will not be the code that is pushed when it is ready.
What you guarantee to happen in the future is irrelevant .. We want
bisection _now_ , not months from now..
Bisection has lots of benefits, it's not just that one stupid
requirement mainline has and no one really cares about.
Daniel
next prev parent reply other threads:[~2008-05-05 17:04 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-02 18:02 Preempt-RT patch for 2.6.25 Remy Bohmer
2008-05-02 18:34 ` Sven-Thorsten Dietrich
2008-05-02 18:45 ` Steven Rostedt
2008-05-02 18:54 ` Sven-Thorsten Dietrich
2008-05-02 19:02 ` Steven Rostedt
2008-05-02 19:14 ` Sven-Thorsten Dietrich
2008-05-03 2:44 ` Steven Rostedt
2008-05-05 14:21 ` Daniel Walker
2008-05-05 16:01 ` Daniel Walker
2008-05-05 16:11 ` Steven Rostedt
2008-05-05 16:19 ` Daniel Walker
2008-05-05 16:44 ` Steven Rostedt
2008-05-05 17:04 ` Daniel Walker [this message]
2008-05-05 18:32 ` Steven Rostedt
2008-05-05 18:58 ` Daniel Walker
2008-05-05 21:01 ` Thomas Gleixner
2008-05-05 22:12 ` Daniel Walker
2008-05-05 23:47 ` Ingo Molnar
2008-05-06 0:11 ` Daniel Walker
2008-05-06 1:30 ` Thomas Gleixner
2008-05-06 1:43 ` Daniel Walker
2008-05-06 8:43 ` Ingo Molnar
2008-05-06 16:01 ` Daniel Walker
2008-05-06 0:13 ` Thomas Gleixner
2008-05-06 1:54 ` Thomas Gleixner
2008-05-06 2:10 ` Daniel Walker
2008-05-06 8:19 ` Thomas Gleixner
2008-05-06 10:40 ` Steven Rostedt
2008-05-06 16:05 ` Daniel Walker
2008-05-06 16:32 ` Steven Rostedt
2008-05-06 17:06 ` Daniel Walker
2008-05-06 20:59 ` Steven Rostedt
2008-05-05 16:17 ` Daniel Walker
2008-05-05 16:21 ` Steven Rostedt
2008-05-05 16:31 ` Daniel Walker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1210007084.17132.32.camel@localhost.localdomain \
--to=dwalker@mvista.com \
--cc=jonathan@jonmasters.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=linux@bohmer.net \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=sven@thebigcorporation.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox