User: Password:
|
|
Subscribe / Log in / New account

Re: linux-next: add utrace tree

From:  Ingo Molnar <mingo-AT-elte.hu>
To:  Stephen Rothwell <sfr-AT-canb.auug.org.au>
Subject:  Re: linux-next: add utrace tree
Date:  Wed, 20 Jan 2010 06:49:50 +0100
Cc:  "Frank Ch. Eigler" <fche-AT-redhat.com>, utrace-devel-AT-redhat.com, linux-next-AT-vger.kernel.org, LKML <linux-kernel-AT-vger.kernel.org>, Thomas Gleixner <tglx-AT-linutronix.de>, "H. Peter Anvin" <hpa-AT-zytor.com>, Peter Zijlstra <peterz-AT-infradead.org>, Linus <torvalds-AT-linux-foundation.org>, Andrew Morton <akpm-AT-linux-foundation.org>, Peter Zijlstra <a.p.zijlstra-AT-chello.nl>, Steven Rostedt <rostedt-AT-goodmis.org>, Arnaldo Carvalho de Melo <acme-AT-redhat.com>, Fr??d??ric Weisbecker <fweisbec-AT-gmail.com>
Archive-link:  Article, Thread


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Frank,
> 
> On Tue, 19 Jan 2010 16:16:46 -0500 "Frank Ch. Eigler" <fche@redhat.com> wrote:
> >
> > Having been reviewed a couple of times, and we hope being a good
> > candidate for merging next time, please start pulling
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git branch master
> 
> I have added this from today with you and utrace-devel as the contacts.
> I have cc'd the wider community on this email so that people are aware
> that this has been included.
> 
> > This repo contains frequent merges from Linus' tree.  If you'd prefer
> > a cleaner rebase-based branch to pull from, we can make one of those too.
> 
> For now it is OK, but you might like to ask Linus if he would like it
> cleaned up before submission since it seems to have history right back to
> 2.6.29 and (as you say) lots of merges with his tree.
> 
> You should also add a commit with an entry in MAINTAINERS.

Note, i'm not yet convinced that this (and the rest: uprobes and systemtap, 
etc.) can go uptream in its present form.

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.

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.

Thanks,

	Ingo


(Log in to post comments)


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds