Anthony Liguori <anth...@codemonkey.ws> writes: > On 05/23/2011 05:30 AM, Daniel P. Berrange wrote: >> 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. > > I agree. But my view of blockdev is that you wouldn't set an fd > attribute but rather the backing file name and use the fd protocol. > For instance: > > -blockdev id=foo-base,path=fd:4,format=raw > -blockdev id=foo,path=fd:3,format=qcow2,backing_file=foo
I guess you mean backing_file=foo-base. If none is specified, use the backing file specification stored in the image. Matches my current thinking.
