From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm5CG-0003ru-27 for qemu-devel@nongnu.org; Tue, 13 Oct 2015 15:25:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zm5CF-00032H-0F for qemu-devel@nongnu.org; Tue, 13 Oct 2015 15:25:16 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Programmingkid In-Reply-To: <87d1wi4woj.fsf@blackfin.pond.sub.org> Date: Tue, 13 Oct 2015 15:25:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0e01e250855f841e56481fe690859bd65e667c4f.1444691409.git.jcody@redhat.com> <87ziznfccm.fsf@blackfin.pond.sub.org> <20151013111726.GA10945@localhost.localdomain> <87d1wi4woj.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, Jeff Cody , qemu-devel@nongnu.org, jsnow@redhat.com On Oct 13, 2015, at 11:26 AM, Markus Armbruster wrote: > Jeff Cody writes: >=20 >> On Tue, Oct 13, 2015 at 09:37:29AM +0200, Markus Armbruster wrote: >>> Jeff Cody writes: >>>=20 >>>> 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. >>>>=20 >>>> This patch enforces the following rules when generating an ID: >>>>=20 >>>> 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). >>>>=20 >>>> The scheme for this is as follows (no spaces): >>>>=20 >>>> # subsys D RR >>>> Reserved char --| | | | >>>> Subsystem String ----| | | >>>> Unique number (64-bit) --| | >>>> Two-digit random number ---| >>>>=20 >>>> For example, a generated node-name for the block sub-system may = look >>>> like this: >>>>=20 >>>> #block076 >>>>=20 >>>> The caller of id_generate() is responsible for freeing the = generated >>>> node name string with g_free(). >>>>=20 >>>> 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(+) >>>>=20 >>>> 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") >>>>=20 >>>> /* id.c */ >>>> + >>>> +typedef enum IdSubSystems { >>>> + ID_QDEV, >>>=20 >>> 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? >>>=20 >>=20 >> 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. >=20 > Then that patch should add ID_QDEV. >=20 >>> You could sidestep these questions by making id_generate() take a = string >>> argument ;) >>>=20 >>=20 >> 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). I can see the benefit of using a string. The id_generate() function could use va_args like printf() uses to allow almost any kind of=20 string argument. An empty string argument could mean to default to ID_MAX. But I also think using an enumeration is good enough, so=20 either way is good.=