utrace/ptrace
in [Kernel]
|
Prev: [PATCH] NOMMU: use copy_*_user_page() in access_process_vm()
Next: [PATCH] spi: Allow using spi_bitbang_setup() with custom txrx_bufs()
From: Christoph Hellwig on 27 Nov 2009 09:10 On Thu, Nov 26, 2009 at 01:24:41PM +0100, Ingo Molnar wrote: > FYI, the merge window has not opened yet, so it cannot close in a few > days. subsystems merged window, not Linus'. > > > [...] 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. None of the recent mm snapshots has anything utrace related in there, just a few ptrace patches from Oleg (which are in this series but a very small part of it) and certainly not all this new code that is pretty recent (take a look at the utrace list for the development). > 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. I'm not sure why you're trying to pick fights here, but no one has said about doing it all in once. The point I'm trying to make is that it's pretty bad to keep parallel ptrace implementations, and we should settle on one. A pre-requisite of using the new once genericly is to have the architecture ptrace code updated. I think arm and mips are the two only relevant ones still missing, so updating them and killing the other ones is easy. If you think keeping the two ptrace implementations is fine argue for that directly, but please stick to the technical points instead of just fighting for fightings sake. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oleg Nesterov on 27 Nov 2009 09:30 On 11/27, Christoph Hellwig wrote: > > On Thu, Nov 26, 2009 at 01:24:41PM +0100, Ingo Molnar wrote: > > > > FYI, it's been in -mm, that's where it's maintained. > > None of the recent mm snapshots has anything utrace related in there, Well, not that I think this is important, but... Two weeks ago we asked Andrew do drop utrace-core.patch from -mm, it should be replaced by this updated version. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 27 Nov 2009 14:20 * Christoph Hellwig <hch(a)infradead.org> wrote: > > 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. > > I'm not sure why you're trying to pick fights here, [...] I am advocating proper engineering practices - not sure why you characterise it as 'picking fights'. > [...] but no one has said about doing it all in once. [...] To quote your mail in (<20091125214818.GA4916(a)infradead.org>): > > [...] I'd suggest you make sure the remaining two major > > architectures (arm and mips) get converted [...] Spreading the impact of these changes to even more architectures is bad, for the reasons i outlined in my previous mail. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 29 Nov 2009 04:10 On Wed 2009-11-25 16:48:18, Christoph Hellwig wrote: > On Tue, Nov 24, 2009 at 09:01:27PM +0100, Oleg Nesterov wrote: > > Hello. > > > > This is the new iteration of Roland's utrace patch, this time > > with "rewrite-ptrace-via-utrace" + cleanups in utrace core. > > > > 1-7 are already in -mm tree, I am sending them to simplify the > > review. > > > > 8-12 don not change the behaviour, simple preparations. > > > > 13-14 add utrace-ptrace and utrace > > Skipped over it very, very briefly. One thing I really hate about this > is that it introduces two ptrace implementation by adding the new one > without removing the old one. 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 don't think introducing regressions to force people to rewrite code is a good way to go... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Roland McGrath on 1 Dec 2009 19:50
Note to all: I'm on the road this week (having had a holiday last week) and will be somewhat slow in replying on these threads, but I will be sure to get to them all. > Yes, nobody likes 2 implementations. I guess Roland and me hate > CONFIG_UTRACE much more than anybody else. :-) We both hate maintaining the old ptrace implementation, that is true! The other thing we hate is having our work delayed arbitrarily again and again to wait for the arch maintainers of arch's we don't use ourselves. Oleg and I have been trying to follow the advice we get on how to get this work merged in. When multiple gate-keepers give conflicting advice, we really don't know what to do next. Our interest is in whatever path smooths the merging of our work. We'd greatly prefer to spend our time hacking on our new code to make it better or different in cool and useful ways than to spend more time guessing what order of patches and rejuggling of the work will fit the changing whims of the next round of review. We don't want to rush anyone, like uninterested arch maintainers. We don't want to break anyone who doesn't care about our work (we do test for ptrace regressions but of course new code will always have new bugs so some instances of instability in the transition to a new ptrace implementation have to be expected no matter how hard we try). We just don't want to keep working out of tree. The advantage of making the new code optional is, obviously, that you can turn it off. That is, lagging arch's won't be broken, just unable to turn it on. And, anyone who doesn't want to try anything new yet can just turn it off and not be exposed to new code. The advantage of making the new code nonoptional is, obviously, that you can't turn it off. The old implementation will be gone and we won't have to maintain it any more (outside some -stable streams for a while). The kernel source will be cleaner with no optional old cruft code duplicating functionality. All ptrace users will be testing the new code, and so we'll find its bugs and gain confidence that it works solidly. Like I've said, we want to do whatever the people want. My concern about what Christoph has suggested is that it really seems like an open-ended delay depending on some arch people who are not even in the conversation. For anyone either who likes utrace or who is concerned about its details, the sooner we are working in-tree the sooner we can really hash it out thoroughly and get to having merged code that works well. As long as there is anything unfinished like arch work that we've decided is a gating event, then the review and hashing out of the new code itself does not seem to get very serious. (To wit, this thread is still talking about merge order and such, another long thread was about incidental trivia, and we've only just started to see a tiny bit of actual code review today.) Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |