On 04/04/2013 05:41:35 AM, Gleb Natapov wrote:
On Tue, Apr 02, 2013 at 08:57:48PM -0500, Scott Wood wrote:
> +struct kvm_device_attr {
> + __u32 flags; /* no flags currently defined */
> + __u32 group; /* device-defined */
> + __u64 attr; /* group-defined */
> + __u64 addr; /* userspace address of attr data */
> +};
> +
Since now each device has its own fd is it an advantage to enforce
common interface between different devices?
I think so, even if only to avoid repeating the various pains
surrounding adding ioctls. Not necessarily "enforce", just enable. If
a device has some sort of command that does not fit neatly into the
"set or get" model, it could still add a new ioctl.
If we do so though why not handle file creation, ioctl and file
descriptor lifetime in the
common code. Common code will have "struct kvm_device" with "struct
kvm_device_arch" and "struct kvm_device_ops" members. Instead of
kvm_mpic_ioctl there will be kvm_device_ioctl which will despatch
ioctls
to a device using kvm_device->ops->(set|get|has)_attr pointers.
So make it more like the pre-fd version, except for the actual fd
usage? It would make destruction a bit simpler (assuming there's no
need for vcpu destruction code to access a device). Hopefully nobody
asks me to change it back again, though. :-)
-Scott
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
