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:	Mon, 5 May 2008 14:32:07 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Daniel Walker <dwalker@...sta.com>
cc:	Sven-Thorsten Dietrich <sven@...bigcorporation.com>,
	Remy Bohmer <linux@...mer.net>,
	LKML <linux-kernel@...r.kernel.org>,
	RT <linux-rt-users@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jon Masters <jonathan@...masters.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: Preempt-RT patch for 2.6.25

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

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