[DTrace-devel] [PATCH v2 03/19] Deprecate enabled probe ID (epid)
Eugene Loh
eugene.loh at oracle.com
Mon Sep 9 18:40:34 UTC 2024
On 9/9/24 13:31, Kris Van Hees wrote:
> On Sun, Sep 08, 2024 at 12:31:12PM -0400, Eugene Loh wrote:
>> On 9/5/24 23:31, Kris Van Hees wrote:
>>> On Tue, Sep 03, 2024 at 01:16:43AM -0400, eugene.loh at oracle.com wrote:
>>>> From: Eugene Loh <eugene.loh at oracle.com>
>>>> Deprecate the use of EPID:
>>>>
>>>> *) So we rearrange as follows:
>>>>
>>>> old new
>>>>
>>>> 0: pad (size) pad (size) <= buffer start
>>>> 4: pad (additional) specid
>>>> 8: epid <= buffer start prid
>>>> 12: specid stid
>>>> 16: data[n] data[n]
>>>>
>>>> So now, we say there is no longer an 8-byte pad before the
>>>> buffer start; rather, the buffer starts with a 4-byte pad.
>>> I am not sure whether this layout comparison is comprehensible to anyone not
>>> familiar with this code.
>> Yeah. Incidentally, I had moved specid so that prid/stid were in the same
>> 8-byte block so that someone could read it as a single 8-byte EPID if they
>> wanted to. I'm assuming you see no value in that. So I moved specid back
>> to where it used to be and I think this simplifies the description of what's
>> going on. Anyhow, I revised this explanation. Hopefully it's sufficient
>> now.
> I like the specid first actually :) Since it reflects the designation of the
> data.
The most recent version of the patch has prid, stid, specid. Is that
fine, or do you want another version that reorders these things? It
seems to me that at some point we should converge on some version of
this stuff and worry less about second-order considerations of things
that do not impact the user. Anyhow, I can make the change. Just tell
me in what order you want these things or whether the most recent
version is fine.
>>>> diff --git a/test/unittest/actions/setopt/tst.badopt.r b/test/unittest/actions/setopt/tst.badopt.r
>>>> @@ -1,16 +1,16 @@
>>>> -- @@stderr --
>>>> -dtrace: error on enabled probe ID 2 (ID 1: dtrace:::BEGIN): couldn't set option "Nixon" to "1": Invalid option name
>>>> +dtrace: error in dt_clause_0 for probe ID 1 (dtrace:::BEGIN): couldn't set option "Nixon" to "1": Invalid option name
>>> Perhaps it would be more efficient to update runtest.sh to support both the
>>> old and the new error reporting output, and changing both into a single unified
>>> form that substitutes changeable elements.
>> I don't get this. First, there is no reason to support the old output...
>> that would be a rather remarkable historical vestige to keep in the code
>> base. Second, it seems simpler and more stringent just to compare to a
>> results file in some simple, straightforward way. You say "perhaps" so I
>> just left it as is.
> I was more thinking about making the output we compare less dependent on how
> things are phrased so that we do not have to update .r files whenever there is
> a change in how we output the data. Except for a test or two that verify the
> exact phrasing we expect.
Okay, but again it seems to me that there are multiple acceptable ways
of doing these things, each way with its own pros and cons. So, do you
want another version of this patch with the requested behavior, or can
we move forward with the patch as it was most recently posted? There
are other ways in which the format of DTrace output could be converted
to some "canonical" form before checking; do we want to embark on such a
project now, or first get USDT functionality out the door to users? I
vote for worrying less about some of this "under the hood" fine tuning
(that doesn't even have unequivocal right/wrong) and more about
delivering features to users.
Anyhow, let me know. I can make the requested change, but am nervous
that we're churning on issues that do not benefit users.
>>> E.g.
>>> dtrace: error on enabled probe ID 2 (ID 1: dtrace:::BEGIN): couldn't set option "Nixon" to "1": Invalid option name
>>>
>>> and
>>>
>>> dtrace: error in dt_clause_0 for probe ID 1 (dtrace:::BEGIN): couldn't set option "Nixon" to "1": Invalid option name
>>>
>>> could both be rewritten using pattern amtching and substitutions to be:
>>>
>>> dtrace: error for probe (dtrace:::BEGIN): couldn't set option "Nixon" to "1": Invalid option name
>>>
>>> and tests that are supposed to exercise specific aspects of the error message
>>> or that depend on specific details could test that explicitly?
More information about the DTrace-devel
mailing list