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

[Ladi Prosek]

On Wed, Feb 1, 2017 at 3:43 PM, Eric Blake <address@hidden> wrote:
> 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.

If I wasn't outnumbered and didn't have a feeling that I already lost
:) I would ask you to show me a couple of real-world IOCTLs that don't
fit the abstraction proposed in this patch. And trade it off against
enabling all the rest that would fit. And I would maybe also say that
done is better than perfect but that might mean crossing the line and
getting muself into trouble :p

But yeah, whoever thought that having ... in a syscall signature is a
good idea should be shamed forever.

>>> 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.

I'll look into it. Thanks!

>> 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
>