Steve Dickson wrote: > Greg Banks wrote: > >> 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? > Yes, and it would have the same value. When I get back from LCA next week I want to look at how one would fit that control mechanism into trace points. > >> 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... > Indeed, but it would be a starting point. > >> 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... > I would hope that there would be *more* tracepoints than dprintks. -- Greg Banks, P.Engineer, SGI Australian Software Group. the brightly coloured sporks of revolution. I don't speak for SGI. -- 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
