> You can program KVM using the well known UNIX file paradigm.
Does anyone know why the API was designed this way? Sending a bunch of ioctls to modify the KVM state seems no better than just having normal function calls for it…
Does anyone know why the API was designed this way? Sending a bunch of ioctls to modify the KVM state seems no better than just having normal function calls for it…
Seeing as how they're mmap()ing the fds, it makes some sense to leverage the other file_operations.
- ioctls on char/blkdevs for either physical or logical devices (which also allow for a 'handle' paradigm of operation, and for event polling via epoll/select)
- sysfs and procfs entries for system and process tunables and data
- debugfs for day to day debugging (which is explicitely unstable and not enabled in most production kernels)
- prctl, fcntl, ...
In addition, all of the above is 'automatically' ported across architectures. Some Linux architecture ports have their own syscall tables (with own numbering) and need to be explicitly modified any time a syscall is added.