On 01/02/2017 06:43, Eric Blake wrote: >>> 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.
Windows ioctl (DeviceIoControl) is a little different from POSIX ioctl, more RPC and less one-size-fits-all bucket for syscallish stuff. It is still a leaky abstraction though. Paolo
