On Wed, Apr 11, 2018 at 08:02:58AM -0500, Eric Blake wrote: > You could always add qemu_fopen/qemu_fclose to match the existing > qemu_open/qemu_close. But you do have a point that you can't call > qemu_close/fclose (because fclose would be left with a stale fd that > might spuriously close something that has been opened in another thread > during the race window), nor fclose/qemu_close. > > The FILE interface may sometimes be easier to work with, but it also > comes with buffering issues that you don't have to worry about when > using the fd interface.
Yeah. I'm using plain qemu_open()/qemu_close() and read/write directly. > Good point - but yes, ideally it should always be possible to pass in an > fd instead of having qemu itself open a file, because there are > execution environments where qemu is intentionally prohibited from > directly calling open() for security reasons (where the management app, > such as libvirt, opens and then passes fds to qemu instead). I've converted qmp_memsave/qmp_pmemsave in extra patches to use qemu_open() (and some additional cleanup). > You are correct that we can't really change the existing interface; so > documenting in the commit message that your choice of names is for > consistency reasons may be sufficient. Will do. Revised patches which should implement all of your suggestions (and the style issue noticed by the bot) as replies to this mail. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9