Re: linux-next: add utrace tree

Stephen Rothwell
2010-01-22T00:17:58Z

[-- Attachment #1: Type: text/plain, Size: 4369 bytes --]

Hi Ingo, Andrew,

Any thoughts?

On Thu, 21 Jan 2010 01:38:22 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 20 Jan 2010 08:29:25 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> >
> >
> > * Ingo Molnar <mingo@elte.hu> wrote:
> >
> > >
> > > * Ananth N Mavinakayanahalli <ananth@in.ibm.com> wrote:
> > >
> > > > On Wed, Jan 20, 2010 at 06:49:50AM +0100, Ingo Molnar wrote:
> > > >
> > > > Ingo,
> > > >
> > > > > Note, i'm not yet convinced that this (and the rest: uprobes and systemtap,
> > > > > etc.) can go uptream in its present form.
> > > >
> > > > Agreed, uprobes is still not upstream ready -- it was an RFC. We are
> > > > working through the comments there to get it ready for merger.
> > > >
> > > > > IMHO the far more important thing to address beyond formalities and workflow
> > > > > cleanliness are the (many) technical observations and objections offered by
> > > > > Peter Zijstra on lkml. Not just the git history but also the abstractions and
> > > > > concepts are messy and should be reworked IMO, and also good and working perf
> > > > > events integration should be achieved, etc.
> > > >
> > > > I think Oleg addressed most of Peter's concerns on utrace when the
> > > > ptrace/utrace patchset was reposted.
> > >
> > > Peter is Cc:-ed and he might want to chime in.
> > >
> > > > Perf integration with uprobes will be done and discussions have started with
> > > > Masami and Frederic. There are a couple of fundamental technical aspects
> > > > (XOL vma vs. emulation; breakpoint insertion through CoW and not through
> > > > quiesce) that need resolution.
> > > >
> > > > > The fact that there's a well established upstream workflow for instrumentation
> > > > > patches, which is being routed around by the utrace/uprobes/systemtap code
> > > > > here is not a good sign in terms of reaching a good upstream solution. Lets
> > > > > hope it works out well though.
> > > >
> > > > Agreed.
> > > >
> > > > On the other hand, having ptrace/utrace in the -next tree will give it a
> > > > lot more testing, while any outstanding technical issues are being addressed.
> > >
> > > Including experimental code that is RFC and which is not certain to go
> > > upstream is certainly not the purpose of linux-next though.
> > >
> > > It will cause conflicts with various other trees and increases the overhead
> > > all around. It also causes us to trust linux-next bugreports less - as it's
> > > not the 'next Linux' anymore. Also, there's virtually no high-level
> > > technical review done in linux-next: the trees are implicitly trusted
> > > (because they are pushed by maintainers), bugs and conflicts are reported
> > > but otherwise it's a neutral tree that includes pretty much any commit
> > > indiscriminately.
> > >
> > > If you need review and testing there's a number of trees you can get
> > > inclusion into.
> >
> > Btw., the utrace code has lived in -mm for quite some time - that's an
> > excellent route as Andrew does thorough review and testing.
> >
> > If Andrew agrees with this particular tree as-is and wants these bits to live
> > in linux-next and have it in -mm that way then that's a fair approach
> > obviously and i have no objections ...
>
> So, what is it to be? In or out?
>
> Frank, please be clear as to which branch you want included (master or
> utrace-ptrace). Also note that neither of those branches matches what
> was posted in the sense that they both have lots of history and merges
> not represented in the patches. (I assume that they do produce the same
> final source tree, though).
>
> > The point is to have at least one relevant maintainer request and track it and
> > then supervise the completion of it (which includes the resolution of all
> > outstanding objections) and then push it to Linus.
>
> If we do include it, it is still possible for people to decide (when the
> next merge window opens) that it is still not ready. It adds a bit of
> maybe unneeded complication to linux-next, but we had the same problem in
> this merge window and we have all survived. :-)
>
> In the end, Linus is the final arbitrator of course.

--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]