Greg Banks wrote: > > These are two separate proposals between which we're trying to find some > commonality. I agree.. a common effort does make the most sense... imho... > > In my proposal, the dprintk()s remain designed primarily for humans > (support staff or kernel developers) to read in conjunction with the > correct source code, but control is made fine-grain to make the > mechanism more controllable. This can be done regardless of whether > trace points are involved and regardless of whether we attempt to > support scripts. I would think it the "fine-grain control mechanism" could also manage trace points as well, true? > > Changing dprintk() to add a trace point is just a way to get some trace > points with strictly minimum changes to callsites. I'm not sure this would be a good idea since, as Trond or Chuck pointed out, there is really not rhyme or reason on where the dprintks live today... > > Replacing dprintk()s with new trace points has more or less the same > result but means more futzing with callsites. Well not if the replacements are well thought out and designed, since there does not have 1-to-1 replacement... > > The maintenance problem of correlating any kind of instrumentation point > in kernel code with scripts living out in userspace exists regardless of > how you choose to implement the instrumentation. > +1 steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
