s390x: cut down on unattached devices

Logically, the css bridge should be attached to the machine.

Signed-off-by Cornelia Huck <[email protected]>

---
 hw/s390x/css-bridge.c | 2 ++
 1 file changed, 2 insertions(+)

hw/s390x/css-bridge.c +2 -0

index c4a9735d71..84d33eafc2 100644
@@ -99,6 +99,8 @@ VirtualCssBus *virtual_css_bus_init(void)
 
     /* Create bridge device */
     dev = qdev_create(NULL, TYPE_VIRTUAL_CSS_BRIDGE);
+    object_property_add_child(qdev_get_machine(), TYPE_VIRTUAL_CSS_BRIDGE,
+                              OBJECT(dev), NULL);
     qdev_init_nofail(dev);
 
     /* Create bus on bridge device */

Logically, the css bridge should be attached to the machine.

Signed-off-by Cornelia Huck <[email protected]>

---
 hw/s390x/css-bridge.c | 2 ++
 1 file changed, 2 insertions(+)

hw/s390x/css-bridge.c +0 -0

index c4a9735d71..84d33eafc2 100644

The autogenerated nics should be treated as any other device; use qdev_set_id() to have them show up under peripheral-anon.

Signed-off-by Cornelia Huck <[email protected]>

---
 hw/s390x/s390-virtio-ccw.c | 2 ++
 1 file changed, 2 insertions(+)

hw/s390x/s390-virtio-ccw.c +2 -0

index a23b8aec9f..830bae9d0f 100644
@@ -35,6 +35,7 @@
 #include "cpu_models.h"
 #include "qapi/qmp/qerror.h"
 #include "hw/nmi.h"
+#include "include/monitor/qdev.h"
 
 S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
 {

@@ -259,6 +260,7 @@ static void s390_create_virtio_net(BusState *bus, const char *name)
 
         dev = qdev_create(bus, name);
         qdev_set_nic_properties(dev, nd);
+        qdev_set_id(dev, NULL);
         qdev_init_nofail(dev);
     }
 }

Quoted 3 lines · Cornelia Huck

The autogenerated nics should be treated as any other device; use qdev_set_id() to have them show up under peripheral-anon.

I think this is fine, but then I ask myself how x86 does this. So I tried to find out how the pc-q35 machine does this but I somehow failed to understand how they do it. Do you have any clue?

Quoted 27 lines

Signed-off-by Cornelia Huck <[email protected]>

---
 hw/s390x/s390-virtio-ccw.c | 2 ++
 1 file changed, 2 insertions(+)

hw/s390x/s390-virtio-ccw.c +2 -0

index a23b8aec9f..830bae9d0f 100644
@@ -35,6 +35,7 @@
 #include "cpu_models.h"
 #include "qapi/qmp/qerror.h"
 #include "hw/nmi.h"
+#include "include/monitor/qdev.h"
 
 S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
 {

@@ -259,6 +260,7 @@ static void s390_create_virtio_net(BusState *bus, const char *name)
 
         dev = qdev_create(bus, name);
         qdev_set_nic_properties(dev, nd);
+        qdev_set_id(dev, NULL);
         qdev_init_nofail(dev);
     }
 }

Quoted 7 lines · On Mon, 4 Dec 2017 12:17:06 +0100 Christian Borntraeger…

Quoted 3 lines · Cornelia Huck

The autogenerated nics should be treated as any other device; use qdev_set_id() to have them show up under peripheral-anon.

I think this is fine, but then I ask myself how x86 does this. So I tried to find out how the pc-q35 machine does this but I somehow failed to understand how they do it. Do you have any clue?

It seems they don't. If you start up a machine with only autogenerated devices, you won't find anything under peripheral{-anon}, but several devices under unattached.

So, maybe we should change this for everything? Or just leave it alone?

(The css-bridge change is a different thing IMO, it clearly should be attached to the machine.)

Quoted 28 lines

Quoted 27 lines

Signed-off-by Cornelia Huck <[email protected]>

---
 hw/s390x/s390-virtio-ccw.c | 2 ++
 1 file changed, 2 insertions(+)

hw/s390x/s390-virtio-ccw.c +2 -0

index a23b8aec9f..830bae9d0f 100644
@@ -35,6 +35,7 @@
 #include "cpu_models.h"
 #include "qapi/qmp/qerror.h"
 #include "hw/nmi.h"
+#include "include/monitor/qdev.h"
 
 S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
 {

@@ -259,6 +260,7 @@ static void s390_create_virtio_net(BusState *bus, const char *name)
 
         dev = qdev_create(bus, name);
         qdev_set_nic_properties(dev, nd);
+        qdev_set_id(dev, NULL);
         qdev_init_nofail(dev);
     }
 }

Quoted 11 lines · Cornelia Huck

Quoted 7 lines · On Mon, 4 Dec 2017 12:17:06 +0100 Christian Borntraeger…

Quoted 3 lines · Cornelia Huck

The autogenerated nics should be treated as any other device; use qdev_set_id() to have them show up under peripheral-anon.

I think this is fine, but then I ask myself how x86 does this. So I tried to find out how the pc-q35 machine does this but I somehow failed to understand how they do it. Do you have any clue?

Quoted 9 lines

It seems they don't. If you start up a machine with only autogenerated devices, you won't find anything under peripheral{-anon}, but several devices under unattached.

So, maybe we should change this for everything? Or just leave it alone?

(The css-bridge change is a different thing IMO, it clearly should be attached to the machine.)

IMHO (try to) change everywhere. The devices are attached to the machine, and them showing up as unattached is misleading. IMHO we still to have the 'is it API or not' question/problem so we need to be careful.

Another think I was wondering about is ids: there are QMP commands which designate devices by path and there are commands which designate by id (and we even have either-or via the same parameter in case of device_del). Since the paths do not seem to be directly assigned/controlled by the user ([1]] but id's are I would argue that ids are easier to understand and use. Would generating an id for each auto-generated device be a good idea?

I'm trying to figure out, how the QAPI is supposed to be used, and feel like. So take my comments with a grain of salt.

[1] One can, but does not have to specify the bus. Libvirt does not seem to for virtio-ccw devices. And if one were to, the other patch in the series could break that code.

info qom-tree shows several devices under unattached that probably should go somewhere.

The css bridge should attach to the machine, as it has a similar purpose as e.g. a pci host bridge.

The autogenerated network devices should be in the same bucket as any other device; I'm just not sure about the way I went about it.

The zpci devices are still problematic: I don't have a good idea where they should show up.

Remaining in the unattached container are the sysbus, memory regions and cpus.

Cornelia Huck (2):
s390x/css: attach css bridge
s390x: attach autogenerated nics

 hw/s390x/css-bridge.c      | 2 ++
 hw/s390x/s390-virtio-ccw.c | 2 ++
 2 files changed, 4 insertions(+)

Quoted 2 lines · Cornelia Huck

info qom-tree shows several devices under unattached that probably should go somewhere.

I think this was reported by me. See
MID: <[email protected]>

I would not mind a Reported-by: Halil Pasic <[email protected]>. Or do you see this differently?

If these are bugs. I would prefer commit messages and titles reflecting this fact.

Otherwise at first glance both patches seem sane.

Regards,
Halil

Quoted 21 lines

The css bridge should attach to the machine, as it has a similar purpose as e.g. a pci host bridge.

The autogenerated network devices should be in the same bucket as any other device; I'm just not sure about the way I went about it.

The zpci devices are still problematic: I don't have a good idea where they should show up.

Remaining in the unattached container are the sysbus, memory regions and cpus.

Cornelia Huck (2):
s390x/css: attach css bridge
s390x: attach autogenerated nics

 hw/s390x/css-bridge.c      | 2 ++
 hw/s390x/s390-virtio-ccw.c | 2 ++
 2 files changed, 4 insertions(+)

Quoted 4 lines · On Tue, 28 Nov 2017 15:17:38 +0100 Halil Pasic <[email protected]> wrote:

Quoted 2 lines · Cornelia Huck

info qom-tree shows several devices under unattached that probably should go somewhere.

Quoted 5 lines

I think this was reported by me. See
MID: <[email protected]>

I would not mind a Reported-by: Halil Pasic <[email protected]>. Or do you see this differently?

Apparently I forgot to add it to the first one. Will do.

Quoted 4 lines

If these are bugs. I would prefer commit messages and titles reflecting this fact.

I don't see this as fixing bugs, more removing oddities.

Quoted 2 lines

Otherwise at first glance both patches seem sane.

Can I count this as an ack, or do you plan to do more review?

Quoted 26 lines

Regards,
Halil

Quoted 21 lines

The css bridge should attach to the machine, as it has a similar purpose as e.g. a pci host bridge.

The autogenerated network devices should be in the same bucket as any other device; I'm just not sure about the way I went about it.

The zpci devices are still problematic: I don't have a good idea where they should show up.

Remaining in the unattached container are the sysbus, memory regions and cpus.

Cornelia Huck (2):
s390x/css: attach css bridge
s390x: attach autogenerated nics

 hw/s390x/css-bridge.c      | 2 ++
 hw/s390x/s390-virtio-ccw.c | 2 ++
 2 files changed, 4 insertions(+)

Quoted 4 lines

Quoted 1 line

Otherwise at first glance both patches seem sane.

Can I count this as an ack, or do you plan to do more review?

Yes I was planning to give it another look. And I do already have questions. Isn't the QOM composition tree API? I mean let's assume the QMP commands working on this tree are not completely useless. How is client code (management software) supposed to work, assumed it can rely on paths of e.g. properties being stable. Just imagine we had this default-cssid property (for the sake of the argument, not like we want it) on the css bridge.

Now if the composition tree is API then these can only be bug fixes (IMHO).

There are also other oddities I've spotted. My idea was to put this composition tree discussion on hold until the vfio-ccw stuff is sorted out. I would certainly like to build a better understanding.

Halil

On 11/28/2017 04:21 PM, Halil Pasic wrote:
[..]

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Otherwise at first glance both patches seem sane.

Can I count this as an ack, or do you plan to do more review?

Quoted 7 lines

Yes I was planning to give it another look. And I do already have questions. Isn't the QOM composition tree API? I mean let's assume the QMP commands working on this tree are not completely useless. How is client code (management software) supposed to work, assumed it can rely on paths of e.g. properties being stable. Just imagine we had this default-cssid property (for the sake of the argument, not like we want it) on the css bridge.

Ping! I would like to get this clarified before proceeding with reviewing this series.

Quoted 11 lines

Now if the composition tree is API then these can only be bug fixes (IMHO).

There are also other oddities I've spotted. My idea was to put this composition tree discussion on hold until the vfio-ccw stuff is sorted out. I would certainly like to build a better understanding.

Halil

[..]

Quoted 15 lines · On Fri, 1 Dec 2017 15:41:21 +0100 Halil Pasic <[email protected]> wrote:

On 11/28/2017 04:21 PM, Halil Pasic wrote:
[..]

Quoted 12 lines

Quoted 4 lines

Quoted 1 line

Otherwise at first glance both patches seem sane.

Can I count this as an ack, or do you plan to do more review?

Yes I was planning to give it another look. And I do already have questions. Isn't the QOM composition tree API? I mean let's assume the QMP commands working on this tree are not completely useless. How is client code (management software) supposed to work, assumed it can rely on paths of e.g. properties being stable. Just imagine we had this default-cssid property (for the sake of the argument, not like we want it) on the css bridge.

Quoted 2 lines

Ping! I would like to get this clarified before proceeding with reviewing this series.

[It might be helpful to not drop cc:s.]

I don't think we really want a static tree. As long as the devices are locateable, it should be fine.

Quoted 18 lines · Cornelia Huck

Quoted 15 lines · On Fri, 1 Dec 2017 15:41:21 +0100 Halil Pasic <[email protected]> wrote:

On 11/28/2017 04:21 PM, Halil Pasic wrote:
[..]

Quoted 12 lines

Quoted 4 lines

Quoted 1 line

Otherwise at first glance both patches seem sane.

Can I count this as an ack, or do you plan to do more review?

Yes I was planning to give it another look. And I do already have questions. Isn't the QOM composition tree API? I mean let's assume the QMP commands working on this tree are not completely useless. How is client code (management software) supposed to work, assumed it can rely on paths of e.g. properties being stable. Just imagine we had this default-cssid property (for the sake of the argument, not like we want it) on the css bridge.

Quoted 5 lines

Quoted 2 lines

Ping! I would like to get this clarified before proceeding with reviewing this series.

[It might be helpful to not drop cc:s.]

Sorry. Wrong button.

Quoted 3 lines

I don't think we really want a static tree. As long as the devices are locateable, it should be fine.

What do you mean by locateable in particular?

Let's say I'm management software guy who want's to access a certain property of a certain device. For that I'm supposed to use qom-get. Now qom-get takes a path as input argument (absolute or relative). The question is, how I'm supposed to figure out this path as management software developer? In other words what is the algorithm?

One naive approach would be, to assume that the path is stable between releases. So I have to figure it out when I'm implementing the stuff, and then it keeps working ever after. I read your answer as this naive approach is wrong.

(BTW I find static also confusing in this context.)

[..]

info qom-tree shows several devices under unattached that probably should go somewhere.

The css bridge should attach to the machine, as it has a similar purpose as e.g. a pci host bridge.

The autogenerated network devices should be in the same bucket as any other device; I'm just not sure about the way I went about it.

The zpci devices are still problematic: I don't have a good idea where they should show up.

Remaining in the unattached container are the sysbus, memory regions and cpus.

Cornelia Huck (2):
s390x/css: attach css bridge
s390x: attach autogenerated nics

 hw/s390x/css-bridge.c      | 2 ++
 hw/s390x/s390-virtio-ccw.c | 2 ++
 2 files changed, 4 insertions(+)

info qom-tree shows several devices under unattached that probably should go somewhere.

The css bridge should attach to the machine, as it has a similar purpose as e.g. a pci host bridge.

The autogenerated network devices should be in the same bucket as any other device; I'm just not sure about the way I went about it.

The zpci devices are still problematic: I don't have a good idea where they should show up.

Remaining in the unattached container are the sysbus, memory regions and cpus.

Cornelia Huck (2):
s390x/css: attach css bridge
s390x: attach autogenerated nics

 hw/s390x/css-bridge.c      | 2 ++
 hw/s390x/s390-virtio-ccw.c | 2 ++
 2 files changed, 4 insertions(+)

Signature · 1 line

2.13.6

Cornelia Huck <[email protected]> [2017-11-28, 02:46PM +0100]:

Quoted 15 lines

info qom-tree shows several devices under unattached that probably should go somewhere.

The css bridge should attach to the machine, as it has a similar purpose as e.g. a pci host bridge.

The autogenerated network devices should be in the same bucket as any other device; I'm just not sure about the way I went about it.

The zpci devices are still problematic: I don't have a good idea where they should show up.

Remaining in the unattached container are the sysbus, memory regions and cpus.

Quoted 12 lines

Cornelia Huck (2):
s390x/css: attach css bridge
s390x: attach autogenerated nics

 hw/s390x/css-bridge.c      | 2 ++
 hw/s390x/s390-virtio-ccw.c | 2 ++
 2 files changed, 4 insertions(+)

Signature · 1 line

2.13.6

Regarding the discussion about whether the QOM tree is API and what exploiters like libvirt should do, Halil asked me to chip in.

This patch is fine from libvirt perspective. I did a quick smoke test and you can have a

Tested-by Bjoern Walk <[email protected]>

for what it's worth.

In general, I kind of agree with Halil. Unless somewhere in QEMU it is documented that the QOM tree is not guaranteed to be stable for exploiters, I'd consider is part of the API. libvirt does use at least some hardcoded paths, most of the time for CPUs in /machine/unattached, so if that relation would change, things break. However, there is also code to traverse the QOM tree recursively and find a path for a given type(?) name. If this is the preferred way, we probably should change this in libvirt to be safe.

Quoted 32 lines · On Tue, 5 Dec 2017 09:59:06 +0100 Bjoern Walk <[email protected]> wrote:

Cornelia Huck <[email protected]> [2017-11-28, 02:46PM +0100]:

Quoted 15 lines

info qom-tree shows several devices under unattached that probably should go somewhere.

The css bridge should attach to the machine, as it has a similar purpose as e.g. a pci host bridge.

The autogenerated network devices should be in the same bucket as any other device; I'm just not sure about the way I went about it.

The zpci devices are still problematic: I don't have a good idea where they should show up.

Remaining in the unattached container are the sysbus, memory regions and cpus.

Quoted 12 lines

Cornelia Huck (2):
s390x/css: attach css bridge
s390x: attach autogenerated nics

 hw/s390x/css-bridge.c      | 2 ++
 hw/s390x/s390-virtio-ccw.c | 2 ++
 2 files changed, 4 insertions(+)

Signature · 1 line

2.13.6

Regarding the discussion about whether the QOM tree is API and what exploiters like libvirt should do, Halil asked me to chip in.

Quoted 6 lines

This patch is fine from libvirt perspective. I did a quick smoke test and you can have a

Tested-by Bjoern Walk <[email protected]>

for what it's worth.

Thanks for checking.

Quoted 9 lines

In general, I kind of agree with Halil. Unless somewhere in QEMU it is documented that the QOM tree is not guaranteed to be stable for exploiters, I'd consider is part of the API. libvirt does use at least some hardcoded paths, most of the time for CPUs in /machine/unattached, so if that relation would change, things break. However, there is also code to traverse the QOM tree recursively and find a path for a given type(?) name. If this is the preferred way, we probably should change this in libvirt to be safe.

OK, with that in mind and as we're now adding a property to check on the css bridge, I vote for including patch 1 now (having a fixed location under /machine looks saner that having to
check /machine/unattached/device[<n>], which might not be stable).

Patch 2 needs more discussion, as I'm not sure whether what I'm doing is the correct way to go about this (and other machines are in the same situation). Not sure whether it is worth trying to attach the zpci devices somewhere.

Quoted 59 lines · Cornelia Huck

Quoted 32 lines · On Tue, 5 Dec 2017 09:59:06 +0100 Bjoern Walk <[email protected]> wrote:

Cornelia Huck <[email protected]> [2017-11-28, 02:46PM +0100]:

Quoted 15 lines

info qom-tree shows several devices under unattached that probably should go somewhere.

The css bridge should attach to the machine, as it has a similar purpose as e.g. a pci host bridge.

The autogenerated network devices should be in the same bucket as any other device; I'm just not sure about the way I went about it.

The zpci devices are still problematic: I don't have a good idea where they should show up.

Remaining in the unattached container are the sysbus, memory regions and cpus.

Quoted 12 lines

Cornelia Huck (2):
s390x/css: attach css bridge
s390x: attach autogenerated nics

 hw/s390x/css-bridge.c      | 2 ++
 hw/s390x/s390-virtio-ccw.c | 2 ++
 2 files changed, 4 insertions(+)

Signature · 1 line

2.13.6

Regarding the discussion about whether the QOM tree is API and what exploiters like libvirt should do, Halil asked me to chip in.

Quoted 6 lines

This patch is fine from libvirt perspective. I did a quick smoke test and you can have a

Tested-by Bjoern Walk <[email protected]>

for what it's worth.

Thanks for checking.

Quoted 9 lines

In general, I kind of agree with Halil. Unless somewhere in QEMU it is documented that the QOM tree is not guaranteed to be stable for exploiters, I'd consider is part of the API. libvirt does use at least some hardcoded paths, most of the time for CPUs in /machine/unattached, so if that relation would change, things break. However, there is also code to traverse the QOM tree recursively and find a path for a given type(?) name. If this is the preferred way, we probably should change this in libvirt to be safe.

OK, with that in mind and as we're now adding a property to check on the css bridge, I vote for including patch 1 now (having a fixed location under /machine looks saner that having to
check /machine/unattached/device[<n>], which might not be stable).

Quoted 5 lines

Patch 2 needs more discussion, as I'm not sure whether what I'm doing is the correct way to go about this (and other machines are in the same situation). Not sure whether it is worth trying to attach the zpci devices somewhere.

I think, if it's kind of API, then fixing sooner is better than fixing later.

I also agree that patch 1 should be higher priority.

Before we do patch 1 I would like having agreed and documented whether this is API or not.

If we decide it's an API, I think we should consider deprecating the current interface, but keep it working for two releases or so. I think nothing speaks against introducing a link form unattached in patch 1 (but I have not tried yet).

On Thu, 7 Dec 2017 18:01:46 +0100

Quoted 41 lines

Quoted 27 lines

Quoted 9 lines

Regarding the discussion about whether the QOM tree is API and what exploiters like libvirt should do, Halil asked me to chip in.

This patch is fine from libvirt perspective. I did a quick smoke test and you can have a

Tested-by Bjoern Walk <[email protected]>

for what it's worth.

Thanks for checking.

Quoted 9 lines

In general, I kind of agree with Halil. Unless somewhere in QEMU it is documented that the QOM tree is not guaranteed to be stable for exploiters, I'd consider is part of the API. libvirt does use at least some hardcoded paths, most of the time for CPUs in /machine/unattached, so if that relation would change, things break. However, there is also code to traverse the QOM tree recursively and find a path for a given type(?) name. If this is the preferred way, we probably should change this in libvirt to be safe.

OK, with that in mind and as we're now adding a property to check on the css bridge, I vote for including patch 1 now (having a fixed location under /machine looks saner that having to
check /machine/unattached/device[<n>], which might not be stable).

Quoted 5 lines

Patch 2 needs more discussion, as I'm not sure whether what I'm doing is the correct way to go about this (and other machines are in the same situation). Not sure whether it is worth trying to attach the zpci devices somewhere.

I think, if it's kind of API, then fixing sooner is better than fixing later.

I also agree that patch 1 should be higher priority.

Before we do patch 1 I would like having agreed and documented whether this is API or not.

Quoted 4 lines

If we decide it's an API, I think we should consider deprecating the current interface, but keep it working for two releases or so. I think nothing speaks against introducing a link form unattached in patch 1 (but I have not tried yet).

No, just no. That's completely overengineered.

Quoted 1 line · Cornelia Huck

On Thu, 7 Dec 2017 18:01:46 +0100

[..]

Quoted 46 lines

Quoted 45 lines

Quoted 27 lines

Quoted 9 lines

Regarding the discussion about whether the QOM tree is API and what exploiters like libvirt should do, Halil asked me to chip in.

This patch is fine from libvirt perspective. I did a quick smoke test and you can have a

Tested-by Bjoern Walk <[email protected]>

for what it's worth.

Thanks for checking.

Quoted 9 lines

In general, I kind of agree with Halil. Unless somewhere in QEMU it is documented that the QOM tree is not guaranteed to be stable for exploiters, I'd consider is part of the API. libvirt does use at least some hardcoded paths, most of the time for CPUs in /machine/unattached, so if that relation would change, things break. However, there is also code to traverse the QOM tree recursively and find a path for a given type(?) name. If this is the preferred way, we probably should change this in libvirt to be safe.

OK, with that in mind and as we're now adding a property to check on the css bridge, I vote for including patch 1 now (having a fixed location under /machine looks saner that having to
check /machine/unattached/device[<n>], which might not be stable).

Quoted 5 lines

Patch 2 needs more discussion, as I'm not sure whether what I'm doing is the correct way to go about this (and other machines are in the same situation). Not sure whether it is worth trying to attach the zpci devices somewhere.

I think, if it's kind of API, then fixing sooner is better than fixing later.

I also agree that patch 1 should be higher priority.

Before we do patch 1 I would like having agreed and documented whether this is API or not.

If we decide it's an API, I think we should consider deprecating the current interface, but keep it working for two releases or so. I think nothing speaks against introducing a link form unattached in patch 1 (but I have not tried yet).

Quoted 2 lines

No, just no. That's completely overengineered.

Which part is totally overengineered? Having it clear what is API and what not? Having this documented? Or caring about our deprecation policy (if it's API)?

Quoted 36 lines

Quoted 35 lines

Quoted 25 lines

Quoted 14 lines

Quoted 8 lines

In general, I kind of agree with Halil. Unless somewhere in QEMU it is documented that the QOM tree is not guaranteed to be stable for exploiters, I'd consider is part of the API. libvirt does use at least some hardcoded paths, most of the time for CPUs in /machine/unattached, so if that relation would change, things break. However, there is also code to traverse the QOM tree recursively and find a path for a given type(?) name. If this is the preferred way, we probably should change this in libvirt to be safe.

OK, with that in mind and as we're now adding a property to check on the css bridge, I vote for including patch 1 now (having a fixed location under /machine looks saner that having to
check /machine/unattached/device[<n>], which might not be stable).

Quoted 5 lines

Patch 2 needs more discussion, as I'm not sure whether what I'm doing is the correct way to go about this (and other machines are in the same situation). Not sure whether it is worth trying to attach the zpci devices somewhere.

I think, if it's kind of API, then fixing sooner is better than fixing later.

I also agree that patch 1 should be higher priority.

Quoted 7 lines

Before we do patch 1 I would like having agreed and documented whether this is API or not.

If we decide it's an API, I think we should consider deprecating the current interface, but keep it working for two releases or so. I think nothing speaks against introducing a link form unattached in patch 1 (but I have not tried yet).

No, just no. That's completely overengineered.

Quoted 4 lines

Which part is totally overengineered? Having it clear what is API and what not? Having this documented? Or caring about our deprecation policy (if it's API)?

You're building a monster to fix a non-existing problem. I will not go down that rabbit hole any further, and just apply patch 1.