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.