Re: [PATCH 3/4] tracing: pass proto and args to DEFINE_TRACE

[Ingo Molnar <mingo@elte.hu>]

* Christoph Hellwig <hch@infradead.org> wrote:

> Then again I'd really wish we could get Steve's recents bits 
> merged for various reasons. [...]

I symphathise with your desire to have the latest and greatest stuff 
upstream right now (i get asked this all the time - _everyone_ wants 
their important stuff upstream, yesterday (and everyone else's 
unstable unnecessary crap should wait)), but there's no way we'll 
rush these new tracing features upstream now. They are not yet 
complete and there's a set of new users whose needs have to be 
observed and designed in.

That is how the upstream development cycle works: stuff added after 
the merge window goes upstream in the next merge window, at the 
earliest. (I.e. in about 2 months from now.)

> [...] The whole DEFINE_TRACE thing only appeared in 2.6.30 and 
> releasing that one kernel with the half-baked inferior version 
> sounds like a really bad idea.

The current upstream code in .30 is fully functional and useful to 
all the subsystems that are making use of it - so your attack on it 
is a bit puzzling to me.

You showed up when, some two weeks ago or so, in the merge window? 
That's generally pretty much the worst time to ask for more 
features. The moral of the story is really: if you feel strongly 
about features in an area, get involved sooner.

Module support (which your complaint really boils down to) was never 
really popular with users of this stuff: the pre-.30 facilities were 
exported to modules all along, but were rarely used from that angle 
(for understandable reasons). Most tracing code contributions and 
enhancements came from the direction of non-modular core kernel 
facilities.

Linus doesnt even _use_ modular kernels - neither do i ;)

Yes, once a facility proves to be successful (this is about the 
fifth version - it all evolved gradually along several kernel 
releases), everyone jumps on it and wants new features, preferably 
yesterday.

Thanks,

	Ingo