Re: [PATCH 3/3] blktrace: fix the original blktrace

[Ingo Molnar <mingo@elte.hu>]

* Jens Axboe <jens.axboe@oracle.com> wrote:

> > One is introduced by "block: get rid of the manual directory counting in blktrace"
> > (f48fc4d32e24c0b6a18aad30305d819bcc68c049). Two are "blktrace: port to tracepoints"
> > (5f3ea37c7716db4e894a480e0c18b24399595b6b). Both commits are in mainline.
> > 
> > Since 2 of the bugs will rarely happen in real-life, and the 3rd 
> > one is a small issue, and we were so close to the release of 
> > .29, so I sent the fixes for -tip tree but not mainline. But if 
> > we are going merge tip/blktrace to .31, I guess it's better to 
> > merge that 3 fixes to .30?
> 
> Since you are the person that worked on it most lately, your 
> opinion matters the most. What do you think, is it ready for 
> 2.6.30 or should it wait for .31?

Yeah. Li, Arnaldo, what do you think?

Delaying them would be quite painful at this stage though - the 
blktrace plugin conversion was done with (ahem) your initial support 
so the commits got (foolishly, in hindsight ;-) interwoven into 300 
commits of the 2.6.30 tracing tree.

Delaying them would also be technically baseless - there are no 
known regressions or bugs in this code. (If you know about bugs then 
please speak up so we can fix them! ;-)

At this last minute stage we can do two things: merge it now or if 
you NAK it then we'll rebase the last ~2 months of the tracing tree 
with hundreds of commits (sigh), destroy its true history in the 
process and eradicate the blktrace bits.

I'd like to avoid the second option if possible as it destroys real 
value (these changes are really nice improvements, a lot of work 
went into them and there's no open regressions so i can see no 
objective reason why they couldnt go upstream now) but it's your 
choice really, you maintain block/* :-)

	Ingo