From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlxaH-0001yB-0W for qemu-devel@nongnu.org; Tue, 13 Oct 2015 07:17:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlxaG-0002vm-3l for qemu-devel@nongnu.org; Tue, 13 Oct 2015 07:17:32 -0400 Date: Tue, 13 Oct 2015 07:17:26 -0400 From: Jeff Cody Message-ID: <20151013111726.GA10945@localhost.localdomain> References: <0e01e250855f841e56481fe690859bd65e667c4f.1444691409.git.jcody@redhat.com> <87ziznfccm.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ziznfccm.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH v3 1/4] util - add automated ID generation utility List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, berto@igalia.com, qemu-block@nongnu.org, qemu-devel@nongnu.org, programmingkidx@gmail.com, jsnow@redhat.com On Tue, Oct 13, 2015 at 09:37:29AM +0200, Markus Armbruster wrote: > Jeff Cody writes: > > > Multiple sub-systems in QEMU may find it useful to generate IDs > > for objects that a user may reference via QMP or HMP. This patch > > presents a standardized way to do it, so that automatic ID generation > > follows the same rules. > > > > This patch enforces the following rules when generating an ID: > > > > 1.) Guarantee no collisions with a user-specified ID > > 2.) Identify the sub-system the ID belongs to > > 3.) Guarantee of uniqueness > > 4.) Spoiling predictability, to avoid creating an assumption > > of object ordering and parsing (i.e., we don't want users to think > > they can guess the next ID based on prior behavior). > > > > The scheme for this is as follows (no spaces): > > > > # subsys D RR > > Reserved char --| | | | > > Subsystem String ----| | | > > Unique number (64-bit) --| | > > Two-digit random number ---| > > > > For example, a generated node-name for the block sub-system may look > > like this: > > > > #block076 > > > > The caller of id_generate() is responsible for freeing the generated > > node name string with g_free(). > > > > Reviewed-by: John Snow > > Reviewed-by: Eric Blake > > Reviewed-by: Alberto Garcia > > Signed-off-by: Jeff Cody > > --- > > include/qemu-common.h | 8 ++++++++ > > util/id.c | 37 +++++++++++++++++++++++++++++++++++++ > > 2 files changed, 45 insertions(+) > > > > diff --git a/include/qemu-common.h b/include/qemu-common.h > > index 0bd212b..2f74540 100644 > > --- a/include/qemu-common.h > > +++ b/include/qemu-common.h > > @@ -246,6 +246,14 @@ int64_t qemu_strtosz_suffix_unit(const char *nptr, char **end, > > #define STR_OR_NULL(str) ((str) ? (str) : "null") > > > > /* id.c */ > > + > > +typedef enum IdSubSystems { > > + ID_QDEV, > > ID_QDEV is not used in this series. Do you intend to use it in a > followup-series? Can we reasonably expect that series will be accepted? > John Arbuckle has a patch on list that uses it. I haven't reviewed it, however - but I guess it depends ultimately on whether qdev will allow autogeneration for its IDs or not. > You could sidestep these questions by making id_generate() take a string > argument ;) > I'd rather avoid having each system specifying a string inline in their code. It is cleaner to have the strings defined in a central location, I think (not to mention, easier to reference). > > + ID_BLOCK, > > + ID_MAX /* last element, used as array size */ > > +} IdSubSystems; > > + > > +char *id_generate(IdSubSystems id); > > bool id_wellformed(const char *id); > > > > /* path.c */ > [...]