On Wed, 2013-02-13 at 23:49 -0600, Scott Wood wrote: > Currently, devices that are emulated inside KVM are configured in a > hardcoded manner based on an assumption that any given architecture > only has one way to do it. If there's any need to access device state, > it is done through inflexible one-purpose-only IOCTLs (e.g. > KVM_GET/SET_LAPIC). Defining new IOCTLs for every little thing is > cumbersome and depletes a limited numberspace. > > This API provides a mechanism to instantiate a device of a certain > type, returning an ID that can be used to set/get attributes of the > device. Attributes may include configuration parameters (e.g. > register base address), device state, operational commands, etc. It > is similar to the ONE_REG API, except that it acts on devices rather > than vcpus. Allright guys, let's take a break for a minute :-) What you seem to be proposing is a whole new construct / API to create "device" objects with "attributes" as a way to avoid adding tons of ioctls to the VM. Then you somewhat "coerce" behaviours (ie. methods) as side effects of setting some of those attributes, and create some kind of rigid API through which any kind of potential device "attribute" needs to be coerced through. Essentially you are trying to re-invent encapsulation of kernel objects manipulated by userspace, we already have several mechanisms for doing just that and you are trying to add yet a new one :-) What about instead using existing mechanisms for doing just that: Make your "create device" return an anonymous file descriptor ! That gives you everything ... private ioctl's which can do whatever the heck you want (attributes, methods, etc...), mmap, etc... Guess what ? That's already what we do for various things like our in-kernel emulated iommu tables as far as I can remember. If your problem is to avoid the bottleneck of having to deal with upstream maintainers for generic VM ioctls every time you add some new platform specific kernel "object" then this is probably a much better approach. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
