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

[Arnaldo Carvalho de Melo]

Em Thu, Mar 26, 2009 at 02:37:32PM +0100, Ingo Molnar escreveu:
> 
> * Jens Axboe <jens.axboe@xxxxxxxxxx> 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/* :-)

Well, after this set of fixes by Li the only problem I'm aware of is the
__trace_note_message, that is using ftrace_vprintk, that I didn't notice
because I wasn't using CFQ when developing it, and that gets the output
of the _ftrace_ plugin wedged, but that doesn't affect normal blktrace
operation.

I'll try to get that fixed somehow today, other than that I'm not aware
of any other problem, so I think it could get into 2.6.30 on the premise
that normal blktrace operation is as stable as before and that the
ftrace plugin is recent work and may still need some fixes.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/