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

[Eric Blake]

On 02/01/2017 07:41 AM, Ladi Prosek wrote:

> 
> Ok, so there are two different aspects that should probably be
> separated. The actual semantics of IOCTL calls is equivalent to the
> semantics of files in general. For files it's stream in, stream out
> (and seeking and such). For IOCTL it's a buffer in, buffer out (and a
> return code). The content is file specific, IOCTL code specific,
> whatever. Definitely not guest agent's business to interpret it. Here
> I think my analogy holds.

I don't.  ioctl() is a leaky abstraction - it exists as the blanket
catch-all do-anything-else-that-doesn't-have-a-dedicated-API.  It is, by
its very nature, non-portable and VERY hard to abstract - because there
is no one abstraction for every possible ioctl code.  I strongly agree
with Dan here that you are going to get nowhere by adding a qga-ioctl
command, because there is no SANE way that you can specify it in QAPI.
Rather, add specific commands for the specific actions you want to
expose, and if the implementation of those specific commands uses a
particular ioctl() under the hood, fine.  But don't directly expose
ioctl() over the wire.


>> It would be possible to design a ioctl API that is more usable if you
>> didn't try to do generic passthrough of arbitrary ioctl commands. Instead
>> provide a QAPI schema that uses a union to provide strongly typed arguments
>> for the ioctl commands you care about using. Or completely separate QAPI
>> commands instead of multiplexing everything into an ioctl command.
> 
> I can add a QAPI command for my specific use case if it's acceptable,

Certainly more palatable, and more likely to gain my acceptance.

> that's not a problem. Although at that point I would probably just go
> back to my plan b and use regular file I/O and guest-file-read. I just
> wanted to be as generic as possible to benefit other use cases as well
> and I ended up with what's basically my stab at RPC ioctl.

The problem is that RPC ioctl is not sanely possible.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature