Munich-Quantum-Software-Stack / QDMI

Quantum Device Management Interface (QDMI)
https://munich-quantum-software-stack.github.io/QDMI/
Apache License 2.0
27 stars 0 forks source link

Removing `QDMI_Device` from library routines #7

Closed echavarria-lrz closed 1 month ago

echavarria-lrz commented 6 months ago

Why do we need the QDMI_Device in any of these routines? Shouldn't it be enough to have, for example, this:

int QDMI_control_pack_qir(QDMI_Device dev, void *qirmod, QDMI_Fragment *frag)
{
    return dev->library.QDMI_control_pack_qir(qirmod, frag);
}

Instead of this:

https://github.com/Munich-Quantum-Software-Stack/QDMI/blob/9baf644040ae782f33e2d5f1b2dc71ea121ed76a/src/qdmi_stubs.c#L17

burgholzer commented 6 months ago

Maybe a follow-up question to the issue itself: Why do we need all these methods at all? Why isn't it possible to simply call

dev->QDMI_control_pack_qir(qirmod, frag);

Maybe I am just overlooking things, but what is the particular reason for the current setup?

ystade commented 6 months ago

Just as a matter of fact, the change suggested by @echavarria-lrz makes two different interfaces of QDMI necessary, one that is called by the tools—that is the one as it stands now—and a second one with the signatures without the device that is implemented by the backends. I just want to mention this and this is neither a reason for or against it.

Regarding @burgholzer 's suggestion: This is a question of what functions should be exposed via the interface. Right now the QDMI_Device is defined in https://github.com/Munich-Quantum-Software-Stack/QDMI/blob/4d4d0dc7c8331f0b2dc43119f2da0a53d2a5c203/include/qdmi_internal.h#L113-L119, which I suppose should be kept internal. Perhaps this just makes the interface more C like when you pass the device to a function instead of invoking a function that is stored in a struct as a pointer.

ystade commented 1 month ago

Resolved by #61.