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 <kw...@redhat.com> > 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