Messages in this thread | | | Date | Wed, 19 Jul 2017 20:50:14 +0200 (CEST) | From | Miroslav Benes <> | Subject | Re: [PATCH v2 1/2] livepatch: introduce shadow variable API |
| |
On Wed, 19 Jul 2017, Petr Mladek wrote:
> On Tue 2017-07-18 15:36:27, Joe Lawrence wrote: > > Who knew naming things was so difficult :) > > > > There's been a bunch of feedback on terminology, so I'll just issue a > > collective reply to Petr's last msg on the topic. These were my > > thoughts on naming clarification: > > > > v1,v2 v3 > > -------------------------------------------------------------- > > obj, original data obj, parent object > > num, numerical description of new data id, data identifier > > new_data data > > new_size data_size > > IMHO, "size" might be enough in the context when it is used.
I agree.
> > > > Miroslav also suggested additional text explaining the id / data > > identifier field. How about something like this: > > > > --- > > > > ================ > > Shadow Variables > > ================ > > > > ... > > > > A global, in-kernel hashtable associates parent pointers and a numeric > > identifier with shadow variable data. > > I would slightly reformulate the above sentece: > > A global, in-kernel hashtable associates pointers to parent objects > and a numeric identifier of the shadow data. > > > Specifically, the parent pointer > > serves as the hashtable key, while the numeric id further filters > > hashtable queries. The numeric identifier is a simple enumeration that > > may be used to describe shadow variable versions (for stacking > > livepatches), class or type (for multiple shadow variables per parent), > > etc. Multiple shadow variables may attach to the same parent object, > > but their numeric identifier distinguises between them.
s/distinguises/distinguishes/
> Sounds good to me.
Yes, thanks for the paragraph. It sounds good combined with Petr's proposal.
Miroslav
| |