On Wed, 2 May 2007 19:11:04 -0400 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> > I didn't know that this was the plan. > > > > The problem I have with this is that once we've merged one part, we're > > committed to merging the other parts even though we haven't seen them yet. > > > > What happens if there's a revolt over the next set of patches? Do we > > remove the core markers patches again? We end up in a cant-go-forward, > > cant-go-backward situation. > > > > I thought the existing code was useful as-is for several projects, without > > requiring additional patching to core kernel. If such additional patching > > _is_ needed to make the markers code useful then I agree that we should > > continue to buffer the markers code in -mm until the > > use-markers-for-something patches have been eyeballed. > > > > My statement was probably not clear enough. The actual marker code is > useful as-is without any further kernel patching required : SystemTAP is > an example where they use external modules to load probes that can > connect either to markers or through kprobes. LTTng, in its current state, > has a mostly modular core that also uses the markers. OK, that's what I thought. > Although some, like Christoph and myself, think that it would benefit to > the kernel community to have a common infrastructure for more than just > markers (meaning common serialization and buffering mechanism), it does > not change the fact that the markers, being in mainline, are usable by > projects through additional kernel modules. > > If we are looking at current "potential users" that are already in > mainline, we could change blktrace to make it use the markers. That'd be a useful demonstration. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
