On 04/09/2019 10:11, Juergen Gross wrote:
> On 04.09.19 10:58, Andrew Cooper wrote:
>> On 04/09/2019 09:40, Jan Beulich wrote:
>>> On 04.09.2019 10:25, Juergen Gross wrote:
>>>> On 03.09.19 17:09, Jan Beulich wrote:
>>>>> On 03.09.2019 17:03, Juergen Gross wrote:
>>>>>> On 03.09.19 16:53, Jan Beulich wrote:
>>>>>>> On 29.08.2019 12:18, Juergen Gross wrote:
>>>>>>>> In order to have unique names when doing lock profiling several
>>>>>>>> local
>>>>>>>> locks "lock" need to be renamed.
>>>>>>> But these are all named simply "lock" for a good reason, including
>>>>>>> because they're all function scope symbols (and typically the
>>>>>>> functions are all sufficiently short). The issue stems from the
>>>>>>> dual use of "name" in
>>>>>>>
>>>>>>> #define _LOCK_PROFILE(name) { 0, #name, &name, 0, 0, 0, 0, 0 }
>>>>>>>
>>>>>>> so I'd rather suggest making this a derivation of a new
>>>>>>>
>>>>>>> #define _LOCK_PROFILE_NAME(lock, name) { 0, #name, &lock, 0, 0,
>>>>>>> 0, 0, 0 }
>>>>>>>
>>>>>>> if there's no other (transparent) way of disambiguating the names.
>>>>>> This will require to use a different DEFINE_SPINLOCK() variant,
>>>>>> so e.g.
>>>>>> DEFINE_SPINLOCK_LOCAL(), which will then include the needed
>>>>>> "static" and
>>>>>> add "@<func>" to the lock profiling name. Is this okay?
>>>>> To be frank - not really. I dislike both, and would hence prefer to
>>>>> stick to what there is currently, until someone invents a transparent
>>>>> way to disambiguate these. I'm sorry for being unhelpful here.
>>>> I think I have found a way: I could add __FILE__ and __LINE__ data to
>>>> struct lock_profile. In lock_prof_init() I could look for non-unique
>>>> lock names and mark those to be printed with the __FILE__ and __LINE__
>>>> data added to the names.
>>>>
>>>> Would you be fine with this approach?
>>> I would be, but I'm afraid Andrew won't (as with any new uses of
>>> __LINE__).
>>
>> The ok-ness of using __LINE__ is inversely proportional to the
>> likelihood of developing a livepatch for this particular build of Xen,
>> and what additional patching delta it would cause through unrelated
>> changes.
>
> Not related to this patch, but to __LINE__ and livepatching: have you
> considered to use the "#line" directive to avoid unrelated diffs?There are ways to play with __LINE__, yes. #line was brought up in the original discussion. As a thought experiment, how would you expect this to be used to simplify a livepatch? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
