|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||Stephen Rothwell <sfr-AT-canb.auug.org.au> |
|| ||Re: linux-next: add utrace tree |
|| ||Wed, 20 Jan 2010 06:49:50 +0100|
|| ||"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>,
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>|
|| ||Article, Thread
* Stephen Rothwell <email@example.com> wrote:
> Hi Frank,
> On Tue, 19 Jan 2010 16:16:46 -0500 "Frank Ch. Eigler" <firstname.lastname@example.org> 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.
to post comments)