RE: [patch 1/2] x86, ptrace: support pebs in ds.c

[Metzger, Markus T]

>-----Original Message-----
>From: Roland McGrath [mailto:roland@xxxxxxxxxx] 
>Sent: Donnerstag, 21. Februar 2008 22:00

>Sorry I haven't replied in this thread sooner.

Thanks for your comments. I hope we get this resolved quickly.


>For the user-level interface, we should not be hasty with cooking up
>hairy ptrace extensions.  Personally, I'd prefer that we never add a
>ptrace-based interface for this (ptrace must die).  I think it will
>fit much better either merged into the interfaces that come from
>perfmon2 integration, or into what replaces ptrace when that comes.

Ptrace seems the natural choice for a debug feature.

When ptrace goes away, I will be happy to integrate this feature into
its successor. But as long as ptrace lives, I think it should support
this.


>But I also don't know of anyone desperate and about to burst from lack
>of BTS functionality.

Intel is waiting for this interface - desperate and about to burst from
lack of it.

For one, Intel's debugger is ready to support this.
Second, Intel would like to see all linux debuggers use this hardware
debugging feature.


>The low-level implementation pieces should gel a bit more in -mm or
>whereever.  They should both get more testing and also get more
>concrete use from the perfmon2 integration effort to iron out their
>internal interface kinks.

I see the two parts (ptrace API and ds.c interface) independent from
each other.

The ptrace API is the user interface for the debugging/BTS aspect of it.
As such, it will remain stable.

The ds.c interface is the kernel interface to DS (which covers both BTS
and PEBS). It is currently used by ptrace (the per-thread BTS part) and
it will be used by perfmon2 (the PEBS part) and by kernel debuggers (the
per-cpu BTS part). 

If we need to change the ds.c interface to better fit perfmon2's needs,
we can easily adapt the ptrace layer without affecting the ptrace API.


>I would like to see all the BTS and DS work wait until after 2.6.25.
>We have a lot of x86 churn in 2.6.25 already, and I think we'd do
>better without adding this wrinkle at the same time.

The ptrace BTS extension has been out for review since 2.6.24 (that is,
2.6.23 was the stable kernel at that time). The ptrace API has been
extensively discussed by mostly Ingo and myself until we agreed on its
usefulness. I have not heard any complaints about the API, since then.

I would suggest that we iron out the ptrace API for 2.6.25. This would
introduce ds.c and a first user. It would allow application debuggers to
use that feature.

For 2.6.26 we would make perfmon2 use the ds.c interface. This would add
a second user to ds.c. It would allow profilers to use that feature.

As soon as a ptrace successor becomes available, we will integrate BTS
support into it. We might want to introduce another layer between ptrace
and ds to share some code. This would leave the ptrace layer almost
empty.


What do you think?


thanks and 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/