* Christoph Hellwig <h...@infradead.org> wrote: > On Thu, Nov 26, 2009 at 10:10:52AM +0100, Ingo Molnar wrote: > > > [...] Given that's it's pretty much too later for the 2.6.33 cycle > > > anyway I'd suggest you make sure the remaining two major architectures > > > (arm and mips) get converted, and if the remaining minor architectures > > > don't manage to get their homework done they're left without ptrace. > > > > I suspect the opinion of the ptrace maintainers matters heavily whether > > it's appropriate for v2.6.33. You are not going to maintain this, they > > are. > > I am whoever like many others going to use it. And throwing in new > code a few days before the merge window closes [...]
FYI, the merge window has not opened yet, so it cannot close in a few days. > [...] and thus not getting any of the broad -next test coverage is a > pretty bad idea. In the end it will be the maintainers ruling but > that doesn't make it a good idea from the engineering point of view. FYI, it's been in -mm, that's where it's maintained. > > Regarding porting it to even more architectures - that's pretty much > > the worst idea possible. It increases maintenance and testing > > overhead by exploding the test matrix, while giving little to end > > result. Plus the worst effect of it is that it becomes even more > > intrusive and even harder (and riskier) to merge. > > But it doesn't. Take a look at what these patches actually do, they > basically introduce a new utrace layer, and (conditionally) rewrite > ptrace to use it. The arch support isn't actually part of these > patches directly but rather the cleanup of the underlying arch ptrace > code to use regsets, tracehooks and co so that the new ptrace code can > use. ( I am aware of its design, i merged the original tracehook patches for x86. ) > What the patches in the current form do is to introduce two different > ptrace implementations, with one used on the architectures getting > most testing and another secondary one for left over embedded or dead > architectures with horrible results. So removing the old one is much > better. The arm ptrace rewrite has already been posted by Roland, btw > including some feedback from Russell, but nothing really happened to > it. Yes. Which is a further argument to not do it like that but to do one arch at a time. Trying to do too much at once is bad engineering. Ingo