Re: linux-next: add utrace tree

[Stephen Rothwell]

Hi Ingo, Andrew,

Any thoughts?

On Thu, 21 Jan 2010 01:38:22 +1100 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
>
> On Wed, 20 Jan 2010 08:29:25 +0100 Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> > 
> > * Ingo Molnar <mingo@xxxxxxx> wrote:
> > 
> > > 
> > > * Ananth N Mavinakayanahalli <ananth@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx
http://www.canb.auug.org.au/~sfr/

Attachment: pgp00000.pgp
Description: PGP signature