>Is there any userspace code avaialble which people can use to play with >this?
Not yet. We are talking to internal teams regarding gdb support. >How do you envisage it being used in the long term? Do you >expect any of >the standard performance tuning tools will be tweaked to >understand this >feature and if so which ones? I would expect debuggers to use it to show an execution trace of the debuggee. The ptrace interface targets application debuggers; kernel debuggers would need a slightly different interface. This saves you a lot of single-stepping through your code to answer the question "how exactly did I get here". I used a similar feature on bare metal XScale to hunt data aborts, which made the task pretty easy. Performance tools, which would be interested in the PEBS part of it, would need to share DS with this debugging feature. When I grep'ed the kernel to see who else used DS, I did not find anybody accessing the DS_SAVE_AREA MSR. When there are multiple users of DS, we would need to introduce some means of managing that resource. We may extend this patch to add support for reading PEBS using ptrace. >I'm generally wondering "how will developers be using this in a year or >two's time?" Application developers will use it via application debuggers. Kernel developers will use it via kgdb; a kernel interface needs to be added to it. This patch provides the hardware access and an application debugger interface. >The patches were horridly wordwrapped. My apologies. Andi already complained and I hoped I got it fixed. I'm working on using a different email client and maybe a different email account. >Is there any likelihood that any other CPUs do now or will in >the future >support any similar feature to this? If so, is an >implementation which is >100% contained to arch/x86 appropriate? I am aware of a trace feature in XScale processors. I think there is also something available for ARM, but I don't know details. If the feature turns out to be really useful, I would, of course, expect (or at least hope) that other CPU's would provide a similar feature. Most of the code is arch specific. If other CPU's share the general BTS layout, some of the ptrace_bts.c code could be shared. Since the implementation only supports x86, I think the code should go into arch/x86 - at least until other CPU's are supported. I would hope that the ptrace interface will be shared across architectures. regards, markus. --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
