From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbZiN-00048Q-8G for qemu-devel@nongnu.org; Tue, 07 Oct 2014 14:42:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbZiH-0007Xl-2w for qemu-devel@nongnu.org; Tue, 07 Oct 2014 14:42:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44242) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbZiG-0007Xa-Pp for qemu-devel@nongnu.org; Tue, 07 Oct 2014 14:42:20 -0400 Message-ID: <54343400.6080509@redhat.com> Date: Tue, 07 Oct 2014 20:42:08 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1412078370-3555-1-git-send-email-armbru@redhat.com> <87iok46kb8.fsf@blackfin.pond.sub.org> <20141002132119.GD30564@stefanha-thinkpad.redhat.com> <542D5284.1060201@suse.de> <87tx3mblhq.fsf@blackfin.pond.sub.org> <542D6127.7040308@suse.de> <87tx3ma56u.fsf@blackfin.pond.sub.org> <542D8E3C.6000207@redhat.com> <87k34c71gi.fsf@blackfin.pond.sub.org> <5433BA8E.9070101@redhat.com> <87ppe413de.fsf@blackfin.pond.sub.org> <5434035E.1040807@redhat.com> <877g0bsp04.fsf@blackfin.pond.sub.org> In-Reply-To: <877g0bsp04.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] IDs in QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, stefanha@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, Anthony Liguori , =?ISO-8859-15?Q?Andreas_F=E4?= =?ISO-8859-15?Q?rber?= Il 07/10/2014 20:39, Markus Armbruster ha scritto: >>>> >> > 1) always use the same restriction when a user creates objects; >>>> >> > >>>> >> > 2) do not introduce restrictions when a user is not using QemuOpts. >>>> >> > >>>> >> > We've been doing (2) so far; often it is just because QMP wrappers also >>>> >> > used QemuOpts, but not necessarily. So object_add just does the same. >>> >> >>> >> We've been doing (2) so far simply because we've never wasted a thought >>> >> on it! Since we're wasting thoughts now: which one do we like better? >> > >> > User interfaces other than QOM have been doing (2) too. > From an implementation point of view, doing nothing is doing (2). > > From an interface point of view, it's (2) only when interfaces bypassing > QemuOpts exist. > >> > netdev-add and device-add have been doing (2) because they use QemuOpts >> > under the hood. > qdev_device_add() uses QemuOpts. Until relatively recently, that was > the only way to create a qdev. Nowadays, you could create one using QOM > directly, bypassing QemuOpts's ID restriction. > > netdev-add is similar iirc. > >> > blockdev-add has been consciously doing (2) for node-name. > Actually, we consciously fixed it to do (1): > > commit 9aebf3b89281a173d2dfeee379b800be5e3f363e > Author: Kevin Wolf > Date: Thu Sep 25 09:54:02 2014 +0200 > > block: Validate node-name > > The device_name of a BlockDriverState is currently checked because it is > always used as a QemuOpts ID and qemu_opts_create() checks whether such > IDs are wellformed. > > node-name is supposed to share the same namespace, but it isn't checked > currently. This patch adds explicit checks both for device_name and > node-name so that the same rules will still apply even if QemuOpts won't > be used any more at some point. > > qemu-img used to use names with spaces in them, which isn't allowed any > more. Replace them with underscores. > >> > chardev-add has been doing (1), and I'd argue that this is a bug in >> > chardev-add. > I'm not sure I got you here. > Nevermind, I've consistently swapped (1) and (2). Paolo