All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ladi Prosek <lprosek@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, mdroth@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH] qga: implement guest-file-ioctl
Date: Wed, 1 Feb 2017 11:50:43 +0100	[thread overview]
Message-ID: <CABdb735fGM9r4tirfOTyK1Jv8oC868nW5rCsNk_X5acoiav1iA@mail.gmail.com> (raw)
In-Reply-To: <20170201102013.GC3232@redhat.com>

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

  reply	other threads:[~2017-02-01 10:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-01 10:06 [Qemu-devel] [PATCH] qga: implement guest-file-ioctl Ladi Prosek
2017-02-01 10:20 ` Daniel P. Berrange
2017-02-01 10:50   ` Ladi Prosek [this message]
2017-02-01 11:03     ` Daniel P. Berrange
2017-02-01 13:41       ` Ladi Prosek
2017-02-01 14:43         ` Eric Blake
2017-02-01 15:43           ` Ladi Prosek
2017-02-01 20:24           ` Paolo Bonzini
2017-02-02 11:05         ` Markus Armbruster
2017-02-06 15:37         ` Denis V. Lunev
2017-02-06 15:50           ` Daniel P. Berrange
2017-02-06 15:50           ` Ladi Prosek
2017-02-06 16:10             ` Alexey Kostyushko
2017-02-07 13:16               ` Ladi Prosek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABdb735fGM9r4tirfOTyK1Jv8oC868nW5rCsNk_X5acoiav1iA@mail.gmail.com \
    --to=lprosek@redhat.com \
    --cc=berrange@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.