[DTrace-devel] [PATCH v2] sdt: consolidate the SDT infrastructure in its own provider framework

Nick Alcock nick.alcock at oracle.com
Fri May 19 16:58:36 UTC 2023


On 18 May 2023, Kris Van Hees uttered the following:

> On Thu, May 18, 2023 at 09:26:32PM +0100, Nick Alcock wrote:
>> On 18 May 2023, Kris Van Hees via DTrace-devel verbalised:
>> 
>> > The various SDT providers are implemented using the same underlying
>> > mechanisms.  A common SDT infrastructure avoids code duplication.
>> 
>> Nice! This is what I was hoping could be done, only it looks like a lot
>> more could be done in the direction than I expected.
>> 
>> However, I'd expect this commit to also rejig at least some of the
>> existing SDT providers in terms of the new infrastructure (that way it
>> would be more obvious that the code being removed and the code being
>> added did the same thing, if they appeared together in the same diff).
>
> This will go in *before* the SDT lockstat and sched providers (and a patch
> will be introduced soonish to also update the proc provider to use this new
> infrastructure), so there is not really anhy rejigging to be done.  In a
> sense, I guess the change-over for the SDT proc provider could be done as
> a first example but right now that is not the priority.  So, lockstat and
> sched will use this new infrastructure first.

It would have made it easier to tell that the refactoring was actually
adding something that was comparable to the original code without having
to pull both up and diff them by eye, that's all. (Though I did that :) ).

>> (actually, if you do that you might even find that git will describe the
>> new file as a copy of one of the old ones with all the non-generic code
>> removed, depending on which approach yields a shorter diff. :) )
>
> (See above.)
>
> Anyway...  does this mean you give your r-b?

Oh yes.

Reviewed-by: Nick Alcock <nick.alcock at oracle.com>

-- 
NULL && (void)



More information about the DTrace-devel mailing list