On 18.11.25 12:47, Kevin Wolf wrote:
Am 18.11.2025 um 08:37 hat Vladimir Sementsov-Ogievskiy geschrieben:
On 17.11.25 13:49, Kevin Wolf wrote:
Hi Vladimir,
I remembered this series and wanted to check what the current status is,
because I seemed to remember that the next step was that you would send
a new version. But reading it again, you're probably waiting for more
input? Let's try to get this finished.
I think yes, I was waiting, but then switched to other tasks.
Am 02.04.2025 um 15:05 hat Vladimir Sementsov-Ogievskiy geschrieben:
On 18.10.24 16:59, Kevin Wolf wrote:
If we want to get rid of the union, I think the best course of action
would unifying the namespaces (so that nodes, exports and devices can't
share the same ID) and then we could just accept a universal 'id' along
with 'child'.
Maybe we can go this way even without explicit restriction (which
should some how go through deprecation period, etc), but simply look
for the id among nodes, devices and exports and if found more than one
parent - fail.
And we document, that id should not be ambiguous, should not match more
than one parent object. So, those who want to use new command will care
to make unique ids.
I don't think such a state is very pretty, but it would be okay for me
as an intermediate state while we go through a deprecation period to
restrict IDs accordingly.
So we could start with blockdev-replace returning an error on ambiguous
IDs and at the same time deprecate them, and only later we would make
creating nodes/devices/exports with the same ID an error.
Hmm, the only question remains, is what/how to deprecate exactly?
We want to deprecate user's possibility to set intersecting
IDs for exports / devices / block-nodes? I think, we don't
have a QAPI-native way to deprecate such thing..
We don't have to be able to express every deprecation in the schema. If
it can be expressed, that's nice, but docs/about/deprecated.rst is the
important part.
May be, add new "uuid" parameter, and deprecate its absence (I doubt
that we can do such deprecation too). And deprecate old IDs? But we
can't deprecate QOM path for this..
I don't think renaming options is necessary.
Hmm, or move to QOM paths for block-nodes and exports? And deprecate
export names and node names?
That would only make sense if we converted the block layer to a QOM
class hierarchy, which would be a project of its own.
Or we can just deprecate intersecting IDs in documentation and start
to print warning, when user make intersecting IDs? But nobody reads
warnings..
Is there a proper way to deprecate such things?
The latter is what I would suggest. docs/about/deprecated.rst and
printing warnings. I think libvirt already keeps all IDs distinct
anyway, so for a large part of users nothing will change.
OK. Now the ball is definitely on my side, next step is v10)
--
Best regards,
Vladimir
