Preempt-RT patch for 2.6.25

Preempt-RT patch for 2.6.25

[Remy Bohmer]

Hello Steven,

I was wondering: Is there a preempt-RT-patch planned for 2.6.25?
I haven't seen one either for any of the 2.6.25-rc kernels at the
usual place (http://www.kernel.org/pub/linux/kernel/projects/rt/),
first time in history...
Am I missing something?

Kind Regards,

Remy

Re: Preempt-RT patch for 2.6.25

[Sven-Thorsten Dietrich]

On Fri, 2008-05-02 at 20:02 +0200, Remy Bohmer wrote:
> Hello Steven,
> 
> I was wondering: Is there a preempt-RT-patch planned for 2.6.25?
> I haven't seen one either for any of the 2.6.25-rc kernels at the
> usual place (http://www.kernel.org/pub/linux/kernel/projects/rt/),
> first time in history...
> Am I missing something?


Daniel has done a port, but I think it dropped some archs so its not
complete.


ftp://source.mvista.com/pub/dwalker/rt/patch-2.6.25-rc9-dw1-broken-out.tar.bz2

and updates, possibly:

ftp://source.mvista.com/pub/dwalker/rt/


His bi-sectability changes are pretty key, and I would like to see those
reviewed and incorporated, even if they apply only to x86.

The RT patch queue generally is a mess today. 
Lots of stuff needs to be folded down into the core patches.

The ins and outs of the softirq code need major clean-up.

There are big issues around apic / hardirq threads that we need to
tackle at multiple levels.

(we are seeing the semis acknowledge the IRQ thread model, where IRQs
may stay masked longer than usual)

per-device irq threads, as Jon Masters has mentioned in his blog, may be
one work-around to get past the legacy stuff in x86.

and with the x86 merge, all this should become easier, so that hopefully
we can extricate the IRQ threads changes in a bisectable way, so we can
address the technical issues that stand in the way of upstream, apart
from PREEMPT_RT.

Sven

Re: Preempt-RT patch for 2.6.25

[Steven Rostedt]

On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:
>
>
> His bi-sectability changes are pretty key, and I would like to see those
> reviewed and incorporated, even if they apply only to x86.

They would be nice, but I'm also in the process of moving patches around
to have the next mainline enhancement up front.

>
> The RT patch queue generally is a mess today.
> Lots of stuff needs to be folded down into the core patches.

I'm starting to fold patches together too.

>
> The ins and outs of the softirq code need major clean-up.

That's my next project after ftrace.

>
> There are big issues around apic / hardirq threads that we need to
> tackle at multiple levels.

This is also being worked on by tglx and Jon Masters.

>
> (we are seeing the semis acknowledge the IRQ thread model, where IRQs
> may stay masked longer than usual)
>
> per-device irq threads, as Jon Masters has mentioned in his blog, may be
> one work-around to get past the legacy stuff in x86.
>
> and with the x86 merge, all this should become easier, so that hopefully
> we can extricate the IRQ threads changes in a bisectable way, so we can
> address the technical issues that stand in the way of upstream, apart
> from PREEMPT_RT.

Yeah, I'll be starting to take a hard crack at getting the irqs as threads
work ready for mainline soon.

As for 2.6.25-rt1, I'm currently working on it. I have the patch queue
ready, but it has some major bugs that I'm stil working out. I did a bit
of clean up in the per-cpu portion as well as some of the mutex code. Now
I need to debug all those changes.

-- Steve

Re: Preempt-RT patch for 2.6.25

[Sven-Thorsten Dietrich]

On Fri, 2008-05-02 at 14:45 -0400, Steven Rostedt wrote:
> On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:

> 
> As for 2.6.25-rt1, I'm currently working on it. I have the patch queue
> ready, but it has some major bugs that I'm stil working out. I did a bit
> of clean up in the per-cpu portion as well as some of the mutex code. Now
> I need to debug all those changes.

Pls post what you have asap, we will all help you debug it.

Thanks

Sven

> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Preempt-RT patch for 2.6.25

[Steven Rostedt]

On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:
>
> On Fri, 2008-05-02 at 14:45 -0400, Steven Rostedt wrote:
> > On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:
>
> >
> > As for 2.6.25-rt1, I'm currently working on it. I have the patch queue
> > ready, but it has some major bugs that I'm stil working out. I did a bit
> > of clean up in the per-cpu portion as well as some of the mutex code. Now
> > I need to debug all those changes.
>
> Pls post what you have asap, we will all help you debug it.

You'll have something today. I like to have a kernel that at least boots
;-)

-- Steve

Re: Preempt-RT patch for 2.6.25

[Sven-Thorsten Dietrich]

On Fri, 2008-05-02 at 15:02 -0400, Steven Rostedt wrote:
> On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:
> >
> > On Fri, 2008-05-02 at 14:45 -0400, Steven Rostedt wrote:
> > > On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:
> >
> > >
> > > As for 2.6.25-rt1, I'm currently working on it. I have the patch queue
> > > ready, but it has some major bugs that I'm stil working out. I did a bit
> > > of clean up in the per-cpu portion as well as some of the mutex code. Now
> > > I need to debug all those changes.
> >
> > Pls post what you have asap, we will all help you debug it.
> 
> You'll have something today. I like to have a kernel that at least boots
> ;-)

Hey that's true for Linux always. Its more fun that way :)

Lets definitely try and make it more bisectable:

I'll be pulling this into OpenSUSE 11 ASAP, so whatever I find I'll send
over!

Thanks !

Sven

Re: Preempt-RT patch for 2.6.25

[Steven Rostedt]

On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:
> On Fri, 2008-05-02 at 15:02 -0400, Steven Rostedt wrote:
> > On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:
> > >
> > > On Fri, 2008-05-02 at 14:45 -0400, Steven Rostedt wrote:
> > > > On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:
> > >
> > > >
> > > > As for 2.6.25-rt1, I'm currently working on it. I have the patch queue
> > > > ready, but it has some major bugs that I'm stil working out. I did a bit
> > > > of clean up in the per-cpu portion as well as some of the mutex code. Now
> > > > I need to debug all those changes.
> > >
> > > Pls post what you have asap, we will all help you debug it.
> >
> > You'll have something today. I like to have a kernel that at least boots
> > ;-)
>
> Hey that's true for Linux always. Its more fun that way :)

I'm fixing quite a bit of paper bag bugs. I'm going to call it a night and
work more on it tomorrow night.

-- Steve

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Fri, 2008-05-02 at 22:44 -0400, Steven Rostedt wrote:
> > > You'll have something today. I like to have a kernel that at least boots
> > > ;-)
> >
> > Hey that's true for Linux always. Its more fun that way :)
> 
> I'm fixing quite a bit of paper bag bugs. I'm going to call it a night and
> work more on it tomorrow night.

What kind of bug are you finding?

Daniel

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Fri, 2008-05-02 at 15:02 -0400, Steven Rostedt wrote:
> On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:
> >
> > On Fri, 2008-05-02 at 14:45 -0400, Steven Rostedt wrote:
> > > On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:
> >
> > >
> > > As for 2.6.25-rt1, I'm currently working on it. I have the patch queue
> > > ready, but it has some major bugs that I'm stil working out. I did a bit
> > > of clean up in the per-cpu portion as well as some of the mutex code. Now
> > > I need to debug all those changes.
> >
> > Pls post what you have asap, we will all help you debug it.
> 
> You'll have something today. I like to have a kernel that at least boots
> ;-)

Download my tree .. It boots in my testing, and it's on 2.6.25 .. If it
doesn't boot for you, just bisect down to the offending patch.. While I
forward ported 2.6.24.4-rt4 to 2.6.25 I bisected several times finding
errors (which reduced debugging time considerably.).

Daniel

Re: Preempt-RT patch for 2.6.25

[Steven Rostedt]

On Mon, 5 May 2008, Daniel Walker wrote:
>
> Download my tree .. It boots in my testing, and it's on 2.6.25 .. If it
> doesn't boot for you, just bisect down to the offending patch.. While I
> forward ported 2.6.24.4-rt4 to 2.6.25 I bisected several times finding
> errors (which reduced debugging time considerably.).
>

Daniel,

Thanks, but the bugs were caused by some of my backporting of other
updates (percpu and ftrace). I have them fixed, but I'm also looking at
rearranging the patch queue as well to get things ready for mainline.

-- Steve

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Fri, 2008-05-02 at 14:45 -0400, Steven Rostedt wrote:
> On Fri, 2 May 2008, Sven-Thorsten Dietrich wrote:
> >
> >
> > His bi-sectability changes are pretty key, and I would like to see those
> > reviewed and incorporated, even if they apply only to x86.
> 
> They would be nice, but I'm also in the process of moving patches around
> to have the next mainline enhancement up front.

Not sure what that has to do with bisect changes?

> >
> > The RT patch queue generally is a mess today.
> > Lots of stuff needs to be folded down into the core patches.
> 
> I'm starting to fold patches together too.

You really want bisection first. The reason is that you don't want ever
growing patches, you want smaller and smaller patches. For instance the
rt-mutex-core.patch is way too large, you wouldn't want to fold my
PICK_FUNCTION changes into that patch since that would just make
rt-mutex-core larger ..


Daniel

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Mon, 2008-05-05 at 12:11 -0400, Steven Rostedt wrote:
> On Mon, 5 May 2008, Daniel Walker wrote:
> >
> > Download my tree .. It boots in my testing, and it's on 2.6.25 .. If it
> > doesn't boot for you, just bisect down to the offending patch.. While I
> > forward ported 2.6.24.4-rt4 to 2.6.25 I bisected several times finding
> > errors (which reduced debugging time considerably.).
> >
> 
> Daniel,
> 
> Thanks, but the bugs were caused by some of my backporting of other
> updates (percpu and ftrace). I have them fixed, but I'm also looking at
> rearranging the patch queue as well to get things ready for mainline.

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. 

Bisection is also required for mainline integration ..

Daniel

Re: Preempt-RT patch for 2.6.25

[Steven Rostedt]

On Mon, 5 May 2008, Daniel Walker wrote:
> You really want bisection first. The reason is that you don't want ever
> growing patches, you want smaller and smaller patches. For instance the
> rt-mutex-core.patch is way too large, you wouldn't want to fold my
> PICK_FUNCTION changes into that patch since that would just make
> rt-mutex-core larger ..
>

Yeah, I already did that ;-)

-- Steve

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Mon, 2008-05-05 at 12:21 -0400, Steven Rostedt wrote:
> On Mon, 5 May 2008, Daniel Walker wrote:
> > You really want bisection first. The reason is that you don't want ever
> > growing patches, you want smaller and smaller patches. For instance the
> > rt-mutex-core.patch is way too large, you wouldn't want to fold my
> > PICK_FUNCTION changes into that patch since that would just make
> > rt-mutex-core larger ..
> >
> 
> Yeah, I already did that ;-)

You already folded my PICK_FUNCTION changes? That's why I mentioned it.

Daniel

Re: Preempt-RT patch for 2.6.25

[Steven Rostedt]

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.

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

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.

-- Steve

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

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

Re: Preempt-RT patch for 2.6.25

[Steven Rostedt]

On Mon, 5 May 2008, Daniel Walker wrote:

>
> That's really the point, you should have started with my version. I
> released my changes long before the 2.6.25 release.

Sorry Daniel but you never proved to me that your version didn't break
anything.  I'm not about to start with something that throws out all the
archs, espically when Thomas has a port of another arch ready for me.


>
> > >
> > > 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)..

But you still need to show that it didn't brake anything, which you have
not.

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

I'll admit I would like a bisectable tree, and patches that are submitted
are bisectable. But the patches are also moved around a bit to get
the queue ready for mainline. That moving itself can break the
bisectability of later patches.

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

Patches that come in now are usually simple fixes. Major developments are
bisectable.

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

Fine, produce your own tree, I'll produce mine.

>
> Bisection has lots of benefits, it's not just that one stupid
> requirement mainline has and no one really cares about.

There is some benefits, but one thing you forget about the -rt patch, is
that there's lots of variables.  A lot of bugs that I found in -rt is not
about a bad patch, but usually because of the way rt works (preemptible
spinlocks and interrupts as threads) that cause breakage, and a lot of
that breakage is from a change in upstream, not the patch series. Having
it bisectable doesn't always help.

-- Steve

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Mon, 2008-05-05 at 14:32 -0400, Steven Rostedt wrote:
> On Mon, 5 May 2008, Daniel Walker wrote:
> 
> >
> > That's really the point, you should have started with my version. I
> > released my changes long before the 2.6.25 release.
> 
> Sorry Daniel but you never proved to me that your version didn't break
> anything.  I'm not about to start with something that throws out all the
> archs, espically when Thomas has a port of another arch ready for me.
> 

No one can prove that code has no bugs.. It's not possible. Yes, my code
_might_ have a defect. Your going to have to come to terms with that if
you use my changes.

Dropping the architectures is something you will need to do anyway for
mainline integration. You'll have to do it for re-writes, and you'll
have to do it for bisection .. Ultimately it a good thing. Additionally
if you drop the architectures now you force people to test and re-port
which mean the port are more likely to work. Right now you really have
no idea of the condition of those ports.

> > > > 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)..
> 
> But you still need to show that it didn't brake anything, which you have
> not.

Your right I haven't , like I said no code is guaranteed bug free. Not
even your code.

> >
> > 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.
> 
> I'll admit I would like a bisectable tree, and patches that are submitted
> are bisectable. But the patches are also moved around a bit to get
> the queue ready for mainline. That moving itself can break the
> bisectability of later patches.

It shouldn't .. If something did break you would need to move another
patch forward to correct it. I would imagine you would want all the
patches related to anything you push forward.

> >
> > 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.
> 
> Patches that come in now are usually simple fixes. Major developments are
> bisectable.

Then there shouldn't be any problems.

> >
> > > 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..
> 
> Fine, produce your own tree, I'll produce mine.

I have my own tree already. Are you obsoleting your tree now?

> >
> > Bisection has lots of benefits, it's not just that one stupid
> > requirement mainline has and no one really cares about.
> 
> There is some benefits, but one thing you forget about the -rt patch, is
> that there's lots of variables.  A lot of bugs that I found in -rt is not
> about a bad patch, but usually because of the way rt works (preemptible
> spinlocks and interrupts as threads) that cause breakage, and a lot of
> that breakage is from a change in upstream, not the patch series. Having
> it bisectable doesn't always help.

Sure not everything can be bisected, but we don't currently have a
choice to bisect or not too .. Users are left to report the bug and hope
the right person sees it.

Daniel

Re: Preempt-RT patch for 2.6.25

[Thomas Gleixner]

Daniel,

On Mon, 5 May 2008, Daniel Walker wrote:
> Dropping the architectures is something you will need to do anyway for
> mainline integration. You'll have to do it for re-writes, and you'll
> have to do it for bisection .. Ultimately it a good thing. Additionally
> if you drop the architectures now you force people to test and re-port
> which mean the port are more likely to work. Right now you really have
> no idea of the condition of those ports.

Dropping architectures just for the sake of bisectability does more
harm than good.

We never dropped architecture support due to a rewrite in course of
the whole preempt-rt series. We never dropped architecture support
when we made parts of the code ready for upstream and made it
bisectable.

Keeping the architecture ports even in a maybe disfunctional state in
the queue is important as we move them along and make the obvious
changes to them so anyone interested to bring them up to date has not
to start from scratch again, which is a major PITA (we just did one
from scratch)

> > > > > Bisection is also required for mainline integration ..

Yes, and if you care to look at the code which was merged into
mainline, then you might notice that it was always made
bisectable. Usually it was rewritten pretty much as well.

> > > > 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)..

With half of the functionality dropped, renames along the line so it
can not be verified whether it ends up to be the same code as it was
before. If you really want to make it bisectable then apply the
necessary rename patches to the queue first, make sure that it does
not result in a code change and then refactor the whole thing.

> > > What you guarantee to happen in the future is irrelevant .. We want
> > > bisection _now_ , not months from now..

We have been there before. kernel development does not follow the "we
want _now_" principle at all. Have you ever tried to yell at Linus "we
want XYZ _now_" ? If you decide to try it, please keep me on CC - I
want to enjoy the show.

> > Fine, produce your own tree, I'll produce mine.
> 
> I have my own tree already. Are you obsoleting your tree now?

Sure, we are happy to trade a queue which has major updates of code
close to mainline integration and has preserved the existing
architecture support for some bisectable artifact.

We went through this kind of discussion several times in the past and
you still seem to believe that you can impose your POV on project
maintainers.

Again, that's not the way it works. 

Nobody will object the refactoring of the queue when it is done in a
cooperative way. By creating a fact and trying to enforce it by any
means you'll only reap controversy and attention, not any real
progress.

> > There is some benefits, but one thing you forget about the -rt patch, is
> > that there's lots of variables.  A lot of bugs that I found in -rt is not
> > about a bad patch, but usually because of the way rt works (preemptible
> > spinlocks and interrupts as threads) that cause breakage, and a lot of
> > that breakage is from a change in upstream, not the patch series. Having
> > it bisectable doesn't always help.
> 
> Sure not everything can be bisected, but we don't currently have a
> choice to bisect or not too .. Users are left to report the bug and hope
> the right person sees it.

Exactly, for the majority of problems with preempt-rt, reporting the
bug and waiting for the person who is able to decode it is the only
choice. The hard to decode problems like subtle races are not
decodable by bisection.

Bisectable problems are pretty rare, because most of the problems are
with PREEMPT_RT, which is a disruptive new feature that only gets
activated late in the queue.

Again, we are of course not opposed to a cooperative effort to make
the queue fully bisectable - as long as it has no drawbacks. That
means gradual steps, which is not rocket science.

Thanks,

	tglx

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Mon, 2008-05-05 at 23:01 +0200, Thomas Gleixner wrote:
> Dan
> Dropping architectures just for the sake of bisectability does more
> harm than good.
> 
> We never dropped architecture support due to a rewrite in course of
> the whole preempt-rt series. We never dropped architecture support
> when we made parts of the code ready for upstream and made it
> bisectable.
> 
> Keeping the architecture ports even in a maybe disfunctional state in
> the queue is important as we move them along and make the obvious
> changes to them so anyone interested to bring them up to date has not
> to start from scratch again, which is a major PITA (we just did one
> from scratch)

In open source code never dies. So I'm not sure where this "From
scratch" stuff is coming from .. 

I've done ports from scratch and it's not that bad.. Not sure what your
porting too.. It would also be a lot easier to do an arch port piece by
piece under a bisectable tree.

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.

> With half of the functionality dropped, renames along the line so it
> can not be verified whether it ends up to be the same code as it was
> before. If you really want to make it bisectable then apply the
> necessary rename patches to the queue first, make sure that it does
> not result in a code change and then refactor the whole thing.

I just review code and boot it in various ways. I don't think binary
compatibility is needed for this. For most code that exists, and most
cases in open source it's not needed either.

> We have been there before. kernel development does not follow the "we
> want _now_" principle at all. Have you ever tried to yell at Linus "we
> want XYZ _now_" ? If you decide to try it, please keep me on CC - I
> want to enjoy the show.

Kernel development is "What is available now?" not what is avaiable in
the future.

If you want to reject code you better have a reason other than "We're
going to make some new code for that (some time in the future) sorry."

I'd like to hear Linus come out and say, "Sorry Thomas we can't include
your HRT cause we're getting a newer HRT in three years, so sorry about
that."

I'm not the one that suffers if Steven doesn't include some sort of
bisect change, the users suffer, development suffers.

> Sure, we are happy to trade a queue which has major updates of code
> close to mainline integration and has preserved the existing
> architecture support for some bisectable artifact.
> 
> We went through this kind of discussion several times in the past and
> you still seem to believe that you can impose your POV on project
> maintainers.
> 
> Again, that's not the way it works. 

Sure it is.. When a maintainer makes a mistake I better speak up, or
they're gonna make a mess of things .. That's a huge chunk of the
process.

> Exactly, for the majority of problems with preempt-rt, reporting the
> bug and waiting for the person who is able to decode it is the only
> choice. The hard to decode problems like subtle races are not
> decodable by bisection.
> 
> Bisectable problems are pretty rare, because most of the problems are
> with PREEMPT_RT, which is a disruptive new feature that only gets
> activated late in the queue.

I don't agree with that .. We don't have bisection you can't even back
up the claim .. Had bisection been an option I'm sure it would have been
used.

Daniel

Re: Preempt-RT patch for 2.6.25

[Ingo Molnar]

* Daniel Walker <dwalker@mvista.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.

So please fix this bug in your refactoring of the queue, so that your 
contribution can be utilized/accepted. There's no obligation on 
maintainers to accept buggy contributions. There's no obligation for you 
to fix this bug in your queue either of course - it's up to you whether 
you want to work with the maintainers so that your contribution can be 
accepted.

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.

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.

	Ingo

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Tue, 2008-05-06 at 01:47 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.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. 

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

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

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

Daniel

Re: Preempt-RT patch for 2.6.25

[Thomas Gleixner]

On Mon, 5 May 2008, Daniel Walker wrote:
> On Mon, 2008-05-05 at 23:01 +0200, Thomas Gleixner wrote:
> > We have been there before. kernel development does not follow the "we
> > want _now_" principle at all. Have you ever tried to yell at Linus "we
> > want XYZ _now_" ? If you decide to try it, please keep me on CC - I
> > want to enjoy the show.
> 
> Kernel development is "What is available now?" not what is avaiable in
> the future.

Interesting. I guess your universe is different from ours. According
to a well accredited dictionary:

development: the act or process of developing; growth; progress

Thanks,

	tglx

Re: Preempt-RT patch for 2.6.25

[Thomas Gleixner]

On Mon, 5 May 2008, Daniel Walker wrote:
> On Tue, 2008-05-06 at 01:47 +0200, Ingo Molnar wrote:
> > * Daniel Walker <dwalker@mvista.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

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Tue, 2008-05-06 at 03:30 +0200, Thomas Gleixner wrote:
> On Mon, 5 May 2008, Daniel Walker wrote:
> > On Tue, 2008-05-06 at 01:47 +0200, Ingo Molnar wrote:
> > > * Daniel Walker <dwalker@mvista.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.

Can you stop with these comments. Lets try to resolve this in civil way.

Daniel

Re: Preempt-RT patch for 2.6.25

[Thomas Gleixner]

On Mon, 5 May 2008, Daniel Walker wrote:
> On Mon, 2008-05-05 at 23:01 +0200, Thomas Gleixner wrote:
> > We have been there before. kernel development does not follow the "we
> > want _now_" principle at all. Have you ever tried to yell at Linus "we
> > want XYZ _now_" ? If you decide to try it, please keep me on CC - I
> > want to enjoy the show.
> 
> Kernel development is "What is available now?" not what is avaiable in
> the future.
> 
> If you want to reject code you better have a reason other than "We're
> going to make some new code for that (some time in the future) sorry."

You miss the point. We reject code which breaks existing functionality.
 
> I'd like to hear Linus come out and say, "Sorry Thomas we can't include
> your HRT cause we're getting a newer HRT in three years, so sorry about
> that."

Good point. HRT is mainline and it went through 300+ patch queues
release cycles until the last bits got finaly merged.

I appreciate your competent input how to do mainline development on
large scale projects. In hindsight I regret that I did not hire you as
my personal "get HRT merged" assistant. That would have saved me a lot
of trouble and time.

Thanks,
	
	tglx

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Tue, 2008-05-06 at 03:54 +0200, Thomas Gleixner wrote:
> On Mon, 5 May 2008, Daniel Walker wrote:
> > On Mon, 2008-05-05 at 23:01 +0200, Thomas Gleixner wrote:
> > > We have been there before. kernel development does not follow the "we
> > > want _now_" principle at all. Have you ever tried to yell at Linus "we
> > > want XYZ _now_" ? If you decide to try it, please keep me on CC - I
> > > want to enjoy the show.
> > 
> > Kernel development is "What is available now?" not what is avaiable in
> > the future.
> > 
> > If you want to reject code you better have a reason other than "We're
> > going to make some new code for that (some time in the future) sorry."
> 
> You miss the point. We reject code which breaks existing functionality.

This point , to me, isn't valid. Even if you think it is, the point was
brought up just recently, after Steven finish port to 2.6.25.

So assuming you think bisection is good, and you think the architectures
should have been included then we should have discussed it a long time
ago when my code was first release.

It's not like -rt is overflowing with patches to evaluate.

Daniel

Re: Preempt-RT patch for 2.6.25

[Thomas Gleixner]

On Mon, 5 May 2008, Daniel Walker wrote:
> On Tue, 2008-05-06 at 03:54 +0200, Thomas Gleixner wrote:
> > On Mon, 5 May 2008, Daniel Walker wrote:
> > > On Mon, 2008-05-05 at 23:01 +0200, Thomas Gleixner wrote:
> > > > We have been there before. kernel development does not follow the "we
> > > > want _now_" principle at all. Have you ever tried to yell at Linus "we
> > > > want XYZ _now_" ? If you decide to try it, please keep me on CC - I
> > > > want to enjoy the show.
> > > 
> > > Kernel development is "What is available now?" not what is avaiable in
> > > the future.
> > > 
> > > If you want to reject code you better have a reason other than "We're
> > > going to make some new code for that (some time in the future) sorry."
> > 
> > You miss the point. We reject code which breaks existing functionality.
> 
> This point , to me, isn't valid. Even if you think it is, the point was
> brought up just recently, after Steven finish port to 2.6.25.

Even if you don't care to put me on CC I pretty much follow the
mailing list. All I can see is your priggish "release" message, but no
sign of prior discussion on how to approach that problem.

> So assuming you think bisection is good, and you think the architectures
> should have been included then we should have discussed it a long time
> ago when my code was first release.

You have "released" code and trees before which were ignored. All for
the same reason: your unwillingness to cooperate.

You create some "works for me" artifact, "release" it pompously and
expect that it is picked up and the work you were not willing to do is
finished by others. If that's not happening then you waste everyones
valuable time with your brashly impertinent and stubborn requests to
enforce your POV on those who have developed and maintained preempt-rt
for years.

If that is your idea of cooperation then please look for a community
and maintainers who are willing to accept that mode of operation.

Thanks,

	tglx

Re: Preempt-RT patch for 2.6.25

[Ingo Molnar]

* Daniel Walker <dwalker@mvista.com> wrote:

> > 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. [...]

this sort of "it was too hard for me but I expect the maintainers to 
clean up the mess" stance, combined with an aggressive, uncompromising, 
demanding tone towards the maintainers of a project wont get you very 
far in contributing to any open-source project. You are not their boss, 
you have to learn to work with them instead of trying to force your 
opinion on them. They clearly try to work with you and gave a 
straightforward technical description of how your contribution would be 
acceptable to the project. All the rest is just a waste of everyone's 
time that could be better spent on improving the project. JFYI.

	Ingo

Re: Preempt-RT patch for 2.6.25

[Steven Rostedt]

On Mon, 5 May 2008, Daniel Walker wrote:
> On Mon, 2008-05-05 at 23:01 +0200, Thomas Gleixner wrote:
> >
> > Keeping the architecture ports even in a maybe disfunctional state in
> > the queue is important as we move them along and make the obvious
> > changes to them so anyone interested to bring them up to date has not
> > to start from scratch again, which is a major PITA (we just did one
> > from scratch)
>
> In open source code never dies. So I'm not sure where this "From
> scratch" stuff is coming from ..

Dropping someones work from the official tree is an insult to the
developer that did that work. The *only* reason to drop code is if it
happens to break something else that already existed or it has been warned
for at least one year that if no one maintains this code it will be
dropped. Dropping it for the sake of making "my work easier" is not an
excuse.

Don't say "well it's only temporary" because it's not. You even expected
the ones that did the work to "re-port" it to your new tree. Sorry Daniel,
that's not the way things happen in Open Source.

>
> I've done ports from scratch and it's not that bad.. Not sure what your
> porting too.. It would also be a lot easier to do an arch port piece by
> piece under a bisectable tree.

Refresh my memory, which ports have you submitted?  I don't recall seeing
a port from scratch that was from you.

-- Steve

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Tue, 2008-05-06 at 10:43 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
> 
> > > 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. [...]
> 
> this sort of "it was too hard for me but I expect the maintainers to 
> clean up the mess" stance, combined with an aggressive, uncompromising, 
> demanding tone towards the maintainers of a project wont get you very 
> far in contributing to any open-source project. You are not their boss, 
> you have to learn to work with them instead of trying to force your 
> opinion on them. They clearly try to work with you and gave a 
> straightforward technical description of how your contribution would be 
> acceptable to the project. All the rest is just a waste of everyone's 
> time that could be better spent on improving the project. JFYI.

It's not "too hard for me" it's a matter of correctness. As if I would
ever say that Ingo ..

I'm not forcing my opinion on anyone. I'm assuming cleanup are
acceptable, especially bisect cleanup (when your code isn't bisectable).
My position is based on that.

You release a dirty -rt tree and expect no one will clean it up, and
further more if they do clean up your code you just toss the work aside
like it's pointless. I take it you don't want clean ups. From my
perspective you should be thanking me.

Had Steven simple said "Please include all the architecture" a month ago
when I released my code, I may have actually done that.

This thread is in no way a plea to get my code included. My code never
had a chance to be included anyway ..

Daniel

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Tue, 2008-05-06 at 06:40 -0400, Steven Rostedt wrote:
> Dropping someones work from the official tree is an insult to the
> developer that did that work. The *only* reason to drop code is if it
> happens to break something else that already existed or it has been warned
> for at least one year that if no one maintains this code it will be
> dropped. Dropping it for the sake of making "my work easier" is not an
> excuse.
> 
> Don't say "well it's only temporary" because it's not. You even expected
> the ones that did the work to "re-port" it to your new tree. Sorry Daniel,
> that's not the way things happen in Open Source.

Steven, this is all out of mainline. It works however we want it to
work.

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

Re: Preempt-RT patch for 2.6.25

[Steven Rostedt]

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

Re: Preempt-RT patch for 2.6.25

[Daniel Walker]

On Tue, 2008-05-06 at 12:32 -0400, Steven Rostedt wrote:
> 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.

You said "byte for byte identical". I assumed when you reviewed the
changes you would see it wasn't changing anything.

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

Who am I to dictate priorities to you? However, that's no excuse for
ignoring something important.

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

Setting a requirement of binary compatibility is un-reasonable. I told
you it wasn't making functional changes, that combined with a concerned
review of the code should have been enough.

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

You have a responsibility as a maintainer .. You have to at least look
at code, and decided exactly how to handle it. You have to decided how
you want to merge the code, and when to merge the code.

Bisection is not an optional feature. It's default acceptable, and it
should have been first on your merge list. 

Instead you didn't want it. You default rejected it. From my perspective
not wanting to merge something like that is itself unreasonable.

How is discussing this shoving my code down your throat?

Daniel

Re: Preempt-RT patch for 2.6.25

[Steven Rostedt]

On Tue, 6 May 2008, Daniel Walker wrote:
> >
> > 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.
>
> Who am I to dictate priorities to you? However, that's no excuse for
> ignoring something important.

It is only important for merging to a new tree, nothing more here. A
bisectable tree is important to make sure all new enhancements can be
tracked to see which feature broke the kernel. The reason we want it
bisectable in Linux, is when a bug appears we can do a binary search
(git-bisect) to find the culprit.

Doing this with the -rt patch doesn't solve that key issue. The reason why
is that new enhancements to the -rt patch happen in small patches. In
fact, by folding in a bunch of patches, we have just lost that ability!
The -rt patch has a bunch of features that it adds to the kernel. Having
the -rt patch queue bisectable doesn't find the bug that was introduced by
a new change to a patch deep in the queue (caused by folding). Ideally,
and I've done this to an extent, is to have each change as a separate
patch. This can help us find which change caused a bug.

Having the -rt patch queue as a bisectable queue (all 350+ patches) ONLY
HELPS IN FORWARD PORTING TO ANOTHER VERSION OF LINUX! That said, it is
usually the maintainers that do this. I have certain points in the queue
that I make sure can compile and test a new feature, to make sure
something didn't break in the port. I don't need each patch of that
feature bisectable, because the feature in the whole may be broken by
something that happened in upstream.


>
> > 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.
>
> Setting a requirement of binary compatibility is un-reasonable. I told
> you it wasn't making functional changes, that combined with a concerned
> review of the code should have been enough.

I told you what to do, and so did Thomas. It's not rocket science, and it
is something I would do to make sure as well. Hell, Ingo and Thomas did
this for the x86 merge which was 10 times more complex than making the -rt
queue bisectable.

This is what you should have done.

1) if you needed to make changes to the code (your renaming), do that at
the end with extra patches.

2) save that final result.

3) go through and modify all the patches to your hearts content, to get a
bisectable queue out the door.

4) compare the end result with the result from step 2.

What's so fscking difficult about the above?????

If Ingo and Thomas told Linus to just accept the x86 merge without doing
this exact thing, and then told Linus that it is his job as maintainer to
review the changes to make sure they are correct, there would have not
been any x86 merge today. In fact, if they had the nerve to do that, they
would have lost all respect in the Linux community.

Guess what? You're doing exactly what I said Ingo and Thomas DID NOT DO!


>
> > 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.
>
> You have a responsibility as a maintainer .. You have to at least look
> at code, and decided exactly how to handle it. You have to decided how
> you want to merge the code, and when to merge the code.

The patch queue is 350+ patches. It is not up to me to go through and sort
out exactly what you did. That would take me a week to look at each
individual patch and know what was in your head. Sorry, that is your
responsibilty to help out here.

>
> Bisection is not an optional feature. It's default acceptable, and it
> should have been first on your merge list.

As I said, the paradigm for the -rt patch is completely different. Having
a bisectable patch queue to go into Linux is to find out where a bug was
introduced. Linux evolves in a simple straight time order of events. This
is not true with the -rt patch. To do this, I would keep all patches
unchanged in the tree, and only add new patches at the end, and never fold
anything. We do this to a point, and after a few releases, we start to
fold patches in that we feel are stable.

Again, having a bisectable -rt tree is to help with forward porting only.
And it doesn't even need to be fully bisectable. Just needs to have
certain points to verify.  Usually a bug is introduced by something that
changed in upstream that gets broken not by one patch in the -rt tree, but
by the new concept that the -rt tree introduces. For example, something
might break because we have interrupts as threads. This isn't found by a
bisectable tree, its found by turning off different configuration options
of the -rt patch.


>
> Instead you didn't want it. You default rejected it. From my perspective
> not wanting to merge something like that is itself unreasonable.

I did not default reject it. I told you what we wanted, and you made
absolutely no effort in complying. So in return, I made absolutely no
effort in looking at what you did.

>
> How is discussing this shoving my code down your throat?


Because you refuse to listen to what we say, and you keep pandering that
your changes are so damn important that we need to forget all our own
principles to listen to the word of Daniel.

-- Steve