Messages in this thread | | | Date | Wed, 6 May 2009 10:12:25 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC, PATCH 0/2] utrace/ptrace: simplify/cleanup ptrace attach |
| |
* Oleg Nesterov <oleg@redhat.com> wrote:
> On 05/04, Andrew Morton wrote: > > > > On Mon, 4 May 2009 12:43:48 -0700 (PDT) > > Roland McGrath <roland@redhat.com> wrote: > > > > > I guess we should take Andrew's advice on this. To me, it > > > makes most sense just to order the -mm patches so utrace comes > > > later, and replace the utrace patch as necessary with a > > > compatible version. Perhaps things would be simpler if we > > > made a separate standalone series or git tree (tip/ptrace?) > > > for ptrace cleanups. > > > > Staging the utrace patch at end-of-series would make sense if > > utrace is not on track for a 2.6.31 merge. > > > > And afaict, this is indeed the case - things seem to have gone a > > bit quiet on the utrace front lately. > > The only goal of current ptrace cleanups is to simplify the > "ptrace over utrace" change (hopefully they make sense by > themselves though). > > I am obviously biased, but imho the only real problem with > utrace-ptrace.patch is the current ptrace code which needs > cleanups.
Yes. But realize the fundamental reason for that: _without_ ptrace-over-utrace the utrace core code is a big chunk of dead code only used on the fringes. I see and agree with all the future uses of utrace, but it's easy to be problem-free if a facility is not used by anything significant.
So a clean ptrace-over-utrace plugin is absolutely needed for utrace to go upstream in v2.6.31. The ftrace plugin alone does not justify it. The real prize here is a (much!) cleaner ptrace code. Once ptrace is driven via utrace and it works, its value (and trust level) will skyrocket.
Ingo
| |