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:
pgpJW0DwRC42T.pgp
Description: PGP signature
