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 -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
