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