It feels to me that turning the current block driver code which just does
open(2) on files, into something which issues events& asynchronously
waits for a file would potentially be quite complex.
You also need to be much more careful from a security POV if the mgmt
app is accepting requests to open arbitrary files from QEMU, to ensure
the filenames are correctly/strictly validated before opening them and
giving them back to QEMU. An architecture where the mgmt app decides
what FDs to supply upfront, has less potential for security errors.
To me the ideal would thus be that we can supply FDs for the backing
store with -blockdev syntax, and that places where QEMU re-opens files
would be enhanced to avoid that need. If there are things we can't do
without closing& re-opening the same file, then perhaps we need some
new ioctl()/fcntl() calls to change those file attributes on the fly.