Thread (71 messages) 71 messages, 21 authors, 2010-01-29

Re: linux-next: add utrace tree

From: Ingo Molnar <hidden>
Date: 2010-01-20 05:50:25
Also in: lkml

Possibly related (same subject, not in this thread)

* Stephen Rothwell [off-list ref] wrote:
Hi Frank,

On Tue, 19 Jan 2010 16:16:46 -0500 "Frank Ch. Eigler" [off-list ref] wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help