On 14.02.26 10:13, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy <[email protected]> writes:
On 04.02.26 15:38, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy <[email protected]> writes:
Now we have blockdev-replace QMP command, which depend on a possibility
to select any block parent (block node, block export, or qdev) by one
unique name. The command fails, if name is ambiguous (i.e., match
several parents of different types). In future we want to rid of this
ambiguity.
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
We have numerous kinds of IDs, i.e. names chosen by the user than need
to be unique, but only among the same kind. For instance, you can't
name two block nodes "foo", but you can name a block node, a block
export, a qdev, and a network backend "foo". Using the same ID for
multiple things is of course a bad idea. Permitting it was also a bad
idea.
Your patch rectifies this design mistake, but only partially. Consider:
* IDs need to be unique with their kind. This is what we have now. I
don't like it.
* IDs need to be unique among their kind and possibly some set of
additional kinds. This is where your patch takes us. I like it even
less, to be honest.
* IDs need to be unique, period. This is what I'd like to have.
I like it. Is it enough to write it so simple in deprecation doc? Or should
we still list all such ids we have in QEMU?
It may be something like:
Any kind of IDs you use to reference objects in QEMU must be unique, any
used ID must reference exactly one object. This includes, but is not limited
to qdev full and relative to "/peripheral/" paths, block-node and block-export
names.
This would serve as a declaration of intent. Better than nothing, I
guess.
To enforce uniqueness, we'll have to create a single table of IDs.
If we make it a set, we can reject duplicate IDs, but can't point to the
other ID. Meh.
If we make it map to the kind of ID, we can report the kind. Something
like "block node name 'foo' clashes with block export ID 'foo'". Feels
adequate.
If we make it map the the object the ID identifies, we can get rid of
existing means to map from ID to object. May or may not be worthwhile.
If we create the single table of IDs now rather than later, we can warn.
Something like "duplicate IDs are deprecated: block node name 'foo'
clashes with block export ID 'foo'". Much more likely to get users'
attention than a note in docs/about/deprecated.rst.
We could even wire it to the "-compat deprecated-input=..." machinery
(I'd assist with that). This would let people test their software is
ready for enforced unique IDs.
Thoughts?
Sounds good. At least, I may try to make a common function, to be used both
on object creation and from blockdev-replace to check for ambiguity.
Now, another thought come in my mind:
Shouldn't we instead of uniting different name-spaces, select qom-path as a
primary source of object referencing?
So, simple reserve "block/export/EXPORT_NAME" for exports and
"block/node/NODE_NAME" for nodes?
I imaging, if we simply "deprecate duplicating IDs", this will force libvirt
and others to include object type into the id, so they may start use block
node names like "block-node-disk1", and block export names like
"block-export-disk1".
We can be proactive, providing a common path for "foldering" IDs.
This way, node-name becomes "relative" QOM path, and may be used in context
where
only node-name could be used (all existing use cases in the API now), but in
interfaces,
where may be used objects of different kinds (like new blockdev-replace) the
full
path is preferred (or even required).
--
Best regards,
Vladimir
