Re: [RFC,PATCH 0/14] utrace/ptrace
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.
Re: [RFC,PATCH 0/14] utrace/ptrace
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. The other thing is that this patchset really doesn't quite justify utrace. It's growing a lot more code without actually growing any useful functionality. What about all those other utrace killer features that have been promised for a long time?
Re: utrace_ptrace task-ptrace
On Fri, Aug 07, 2009 at 02:19:10PM -0700, Piet Delaney wrote: Roland McGrath wrote: Only a few arch's overload -ptrace for private purposes, and I don't foresee any problem getting those fixed up soon. (The parisc maintainer is doing it already. I think xtensa might have something on deck. I can do the arm changes if anybody will ever review and merge them.) I thought I check on xtensa having something on deck. I'd like to test it if possible to avoid surprises and if it's not ready, and needs to be, then to include this while submitting SMP changes in the not too distant future. While not directly related to that issue it would be good if you could take a look at http://sourceware.org/systemtap/wiki/utrace/arch/HowTo and convert xtensa to new-style ptrace code described there. That should also make your future maintaince easier by requiring less and better structured architecture code.
Re: utrace_ptrace task-ptrace
On Tue, Aug 04, 2009 at 06:09:11PM -0700, Roland McGrath wrote: I agree, CONFIG_UTRACE_PTRACE should die. But what about !CONFIG_UTRACE case? What should we do with arches which doesn't use tracehooks or play with ptrace internals? AIUI hch wants to have ptrace rely on utrace. Those either get no ptrace (we cond_syscall it) and/or just stop building if not updated. Maybe he can give you some more direct advice about what the merging plan should be. The tracehook conversion is pretty simple for every arch, even for non-arch people (if you just punt the syscall-abort support, which is a new feature and so a non-regressing incremental step). Really architectures should be converted, and it would help if someone else could ping the outstanding architectures again. At some point if they are few enough we can just break them. Firstly, these changes can't be applied until we fix arch/ which play with -ptrace. Only a few arch's overload -ptrace for private purposes, and I don't foresee any problem getting those fixed up soon. (The parisc maintainer is doing it already. I think xtensa might have something on deck. I can do the arm changes if anybody will ever review and merge them.) Converting the architectures to tracehooks and new-style ptrace should mostly take care of it like for parisc. As for arm you might have to push it a bit more, it didn't seem like rmk was very excited about your first set of patches.
LF Collab Summit tracing round table action item
These are the notes and action items for the Tracing roundtable at the Linux Foundation Collaboration summit, April 8-10 in San Francisco. Attendes: Renzo Davoli, Mathieu Desnoyers, Jake Edge, Frank Ch. Eigler, Christoph Hellwig, Masami Hiramatsu, Jim Keniston, Roland McGrath, Steven Rostedt, Josh Stone, Elena Zannoni Kernel Tracing items: - make DEFINE_TRACE work in modules (Steve) - investigate markers removal (Christoph, Matthew) - the 25 magic google tracpoints (Matthew) - make the two major tracepoint implementations interchangeable at the API level (Matthew, Steve) - get djprobes and the instruction decoder upstream (Masami) Utrace and userspace probing: - get arm and mips converted to regsets and uprobes, set a cut off date for others (Christoph, Roland) - more ptrace cleanups to prepare for utrace (Oleg) - in-kernel gdb server for debugging userspace (Frank) - get uprobes upstream piecemail, including backing the gdbserver (Jim)
Re: CONFIG_HAVE_ARCH_TRACEHOOK and you
On Thu, Sep 11, 2008 at 07:57:33PM -0700, Roland McGrath wrote: 3. arch_ptrace() * You must define arch_ptrace() and not #define __ARCH_SYS_PTRACE. __ARCH_SYS_PTRACE is already gone :) 4. compat_arch_ptrace() * If your arch uses CONFIG_COMPAT, you must define compat_arch_ptrace() and #define __ARCH_WANT_COMPAT_SYS_PTRACE. This should be gone for 2.6.28, too. (no ACK from the ia64 people yet, but mips and parisc are doen for sure)
