On Wed, Feb 1, 2017 at 3:43 PM, Eric Blake <ebl...@redhat.com> 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 >
