Re: [Qemu-devel] IDs in QOM

[Paolo Bonzini]

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 <address@hidden>
> 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