On Wed, Mar 06, 2013 at 01:48:33PM +1100, Benjamin Herrenschmidt wrote: > 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 was faster that I predicted! :) http://www.spinics.net/lists/kvm/msg86687.html last paragraph. > 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. > -- Gleb. -- 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
