qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] qga: implement guest-file-ioctl


From: Ladi Prosek
Subject: Re: [Qemu-devel] [PATCH] qga: implement guest-file-ioctl
Date: Wed, 1 Feb 2017 11:50:43 +0100

On Wed, Feb 1, 2017 at 11:20 AM, Daniel P. Berrange <address@hidden> 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/ :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]