Re: [Xen-devel] [PATCH v3 5/5] xen: modify several static locks to unique names

[Juergen Gross <jgross@xxxxxxxx>]

On 04.09.19 11:15, Andrew Cooper wrote:
> 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?
It should be rather strait forward to write a tool adding #line
directives to a patch recovering the previous line numbers in the
code following a modification which added or removed lines.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel