Re: [PATCH 3/3] utrace-based ftrace process engine, v2
* Roland McGrath rol...@redhat.com wrote: From: Frank Ch. Eigler f...@redhat.com This is v2 of the prototype utrace-ftrace interface. This code is based on Roland McGrath's utrace API, which provides programmatic hooks to the in-tree tracehook layer. This new patch interfaces many of those events to ftrace, as configured by a small number of debugfs controls. Here's the /debugfs/tracing/process_trace_README: Please submit changes/enhancements to kernel/trace/* to the tracing tree maintainers (Steve and me) for review, testing and integration. Please also post patches against the latest tracing tree: http://people.redhat.com/mingo/tip.git/README As this patch does not apply: Applying patch patches/utrace-based-ftrace-process-engine-v2.patch patching file include/linux/processtrace.h patching file kernel/trace/Kconfig Hunk #1 succeeded at 186 with fuzz 2 (offset 36 lines). patching file kernel/trace/Makefile Hunk #1 FAILED at 33. 1 out of 1 hunk FAILED -- rejects in file kernel/trace/Makefile patching file kernel/trace/trace.h Hunk #1 succeeded at 7 with fuzz 1. Hunk #2 FAILED at 31. Hunk #3 succeeded at 215 with fuzz 2 (offset 43 lines). Hunk #4 FAILED at 330. 2 out of 4 hunks FAILED -- rejects in file kernel/trace/trace.h patching file kernel/trace/trace_process.c Patch patches/utrace-based-ftrace-process-engine-v2.patch does not apply (enforce with -f) Thanks, Ingo
Re: [PATCH 3/3] utrace-based ftrace process engine, v2
On Sat, 21 Mar 2009 08:43:01 +0100 Ingo Molnar mi...@elte.hu wrote: * Roland McGrath rol...@redhat.com wrote: From: Frank Ch. Eigler f...@redhat.com This is v2 of the prototype utrace-ftrace interface. This code is based on Roland McGrath's utrace API, which provides programmatic hooks to the in-tree tracehook layer. This new patch interfaces many of those events to ftrace, as configured by a small number of debugfs controls. Here's the /debugfs/tracing/process_trace_README: Please submit changes/enhancements to kernel/trace/* to the tracing tree maintainers (Steve and me) for review, testing and integration. Please also post patches against the latest tracing tree: http://people.redhat.com/mingo/tip.git/README uhm, this patch depends on the (large) utrace patch, which is not kernel/trace material. As this patch does not apply: Applying patch patches/utrace-based-ftrace-process-engine-v2.patch patching file include/linux/processtrace.h patching file kernel/trace/Kconfig Hunk #1 succeeded at 186 with fuzz 2 (offset 36 lines). patching file kernel/trace/Makefile Hunk #1 FAILED at 33. 1 out of 1 hunk FAILED -- rejects in file kernel/trace/Makefile patching file kernel/trace/trace.h Hunk #1 succeeded at 7 with fuzz 1. Hunk #2 FAILED at 31. Hunk #3 succeeded at 215 with fuzz 2 (offset 43 lines). Hunk #4 FAILED at 330. 2 out of 4 hunks FAILED -- rejects in file kernel/trace/trace.h patching file kernel/trace/trace_process.c Patch patches/utrace-based-ftrace-process-engine-v2.patch does not apply (enforce with -f) The rejects are trivial.
Re: [PATCH 2/3] utrace core
On Fri, 20 Mar 2009 18:41:40 -0700 (PDT) Roland McGrath rol...@redhat.com wrote: This adds the utrace facility, a new modular interface in the kernel for implementing user thread tracing and debugging. This fits on top of the tracehook_* layer, so the new code is well-isolated. The new interface is in linux/utrace.h and the DocBook utrace book describes it. It allows for multiple separate tracing engines to work in parallel without interfering with each other. Higher-level tracing facilities can be implemented as loadable kernel modules using this layer. The new facility is made optional under CONFIG_UTRACE. When this is not enabled, no new code is added. It can only be enabled on machines that have all the prerequisites and select CONFIG_HAVE_ARCH_TRACEHOOK. In this initial version, utrace and ptrace do not play together at all. If ptrace is attached to a thread, the attach calls in the utrace kernel API return -EBUSY. If utrace is attached to a thread, the PTRACE_ATTACH or PTRACE_TRACEME request will return EBUSY to userland. The old ptrace code is otherwise unchanged and nothing using ptrace should be affected by this patch as long as utrace is not used at the same time. In the future we can clean up the ptrace implementation and rework it to use the utrace API. I'd be interested in seeing a bit of discussion regarding the overall value of utrace - it has been quite a while since it floated past. I assume that redoing ptrace to be a client of utrace _will_ happen, and that this is merely a cleanup exercise with no new user-visible features? The prototype utrace-ftrace interface seems to be more a cool toy rather than a serious new kernel feature (yes?) If so, what are the new killer utrace clients which would justify all these changes? Also, is it still the case that RH are shipping utrace? If so, for what reasons and what benefits are users seeing from it? And I recall that there were real problems wiring up the Feb 2007 version of utrace to the ARM architecture. Have those issues been resolved? Are any problems expected for any architectures? Thanks.
Re: [PATCH 2/3] utrace core
On Sat, Mar 21, 2009 at 03:34:57PM +0100, Ingo Molnar wrote: * Renzo Davoli re...@cs.unibo.it wrote: Tracing does not mean only debug. Some tracing facilities can be used for virtualization. For example User-Mode Linux is based on ptrace. I have a prototype of kernel module for virtualization (kmview) based on utrace. [...] Hm, i cannot find the source code. Can it be downloaded from somewhere? Sure! kmview is not included in our Debian packages yet as it relies on (still) non mainstream features (utrace), but the code is available on our view-os svn repository. Check out: svn co https://view-os.svn.sourceforge.net/svnroot/view-os view-os More specifically to browse the code/specifications: The kmview device protocol is here: http://wiki.virtualsquare.org/index.php/KMview_module_interface_specifications The kernel module itself is here: http://view-os.svn.sourceforge.net/viewvc/view-os/trunk/kmview-kernel-module/ The VMM userland application share most of the code with umview, the source code for both is here: http://view-os.svn.sourceforge.net/viewvc/view-os/trunk/xmview-os/xmview/ kmview kernel module (current version) needs the following patches: utrace http://www.mail-archive.com/utrace-devel@redhat.com/msg00654.html http://www.mail-archive.com/utrace-devel@redhat.com/msg00655.html I am trying to keep everything up to date, but the whole stuff is evolving in a quite fast way. Everything has been released under GPLv2. renzo
Re: [PATCH 3/3] utrace-based ftrace process engine, v2
Hi - On Sat, Mar 21, 2009 at 02:34:13PM -0700, Andrew Morton wrote: [...] It would not be good to merge a large kernel feature which kernel developers and testers cannot test, and regression test. It does not. Other kernel self-sufficient utrace clients are on their way, and of course one was just (re)posted. If testing utrace against its main application requires installation of a complete enterprise distro from a distro [...] This has *never* been a requirement. - FChE
Re: [PATCH 3/3] utrace-based ftrace process engine, v2
On Sat, 21 Mar 2009, Frank Ch. Eigler wrote: If testing utrace against its main application requires installation of a complete enterprise distro from a distro [...] This has *never* been a requirement. You guys are getting off a tangent. Let's go back to the post that started this all. The thing is, utrace crashes in Fedora have dominated kerneloops.org for many months, so i'm not sure what to make of the idea of posting a 4000+ lines of core kernel code patchset on the last day of the development cycle, a posting that has carefully avoided the Cc:-ing of affected maintainers ;-) .. and dammit, I agree 100%. If utrace really shows up in _any_ way on kerneloops.org, then I think THE ENTIRE DISCUSSION in this thread is moot. I'm not going to take known-bad crap. It's that simple. Don't bother posting it, don't bother discussing it, don't bother making excuses for it. Linus
