On Wed, Feb 1, 2017 at 11:20 AM, Daniel P. Berrange <berra...@redhat.com> wrote: > On Wed, Feb 01, 2017 at 11:06:46AM +0100, Ladi Prosek wrote: >> Analogous to guest-file-read and guest-file-write, this commit adds >> support for issuing IOCTLs to files in the guest. With the goal of >> abstracting away the differences between Posix ioctl() and Win32 >> DeviceIoControl() to provide one unified API, the schema distinguishes >> between input and output buffer sizes (as required by Win32) and >> allows the caller to supply either a 'buffer', pointer to which will >> be passed to the Posix ioctl(), or an integer argument, passed to >> ioctl() directly. > > What is the intended usage scenario for this ?
My specific case is extracting a piece of data from Windows guests. Guest driver exposes a file object with a well-known IOCTL code to return a data structure from the kernel. > The size of arguments that need to be provided to ioctl()s vary on > the architecture of the guest kernel that's running, which cannot be > assumed to be the same as the architecture of the QEMU binary. ie > you can be running i686 kernel in an x86_64 QEMU. So it feels like > it is going to be hard for applications to reliably use this feature > unless they have more information about the guest OS, that is not > currently provided by QEMU guest agent. So it feels like this design > is not likely to be satisfactory to me. I can turn this around and say that guest-file-read and guest-file-write shouldn't exist because applications can't reliably know what the format of files on the guest is. This is just a transport, it doesn't need to understand the data it's transporting. Yes, I get it that ioctl tends to be associated with system-y things with tighter ties to the OS, bitness, endianness and so on. But, it doesn't have to be. In my case I chose ioctl as opposed to regular file I/O because what I'm reading is not a stream in nature, it's a fixed size data structure. Thanks! Ladi > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
