From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754886AbdGSPT4 (ORCPT ); Wed, 19 Jul 2017 11:19:56 -0400 Received: from mx2.suse.de ([195.135.220.15]:39013 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754395AbdGSPTy (ORCPT ); Wed, 19 Jul 2017 11:19:54 -0400 Date: Wed, 19 Jul 2017 17:19:51 +0200 From: Petr Mladek To: Joe Lawrence Cc: Miroslav Benes , Josh Poimboeuf , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Jessica Yu , Jiri Kosina Subject: Re: [PATCH v2 1/2] livepatch: introduce shadow variable API Message-ID: <20170719151951.GL32632@pathway.suse.cz> References: <1498664247-12296-1-git-send-email-joe.lawrence@redhat.com> <1498664247-12296-2-git-send-email-joe.lawrence@redhat.com> <20170714004149.6jgg4vxmjsotlkus@treble> <20170718130047.GG3393@pathway.suse.cz> <20170718193627.bzfgprzjjenvcgmc@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170718193627.bzfgprzjjenvcgmc@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > 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. Sounds good to me. Best Regards, Petr