On Thu, Sep 01, 2011 at 03:26:01PM -0500, Scott Wood wrote: > On 09/01/2011 03:00 PM, Michael S. Tsirkin wrote: > > That's a very rich interface, and easy to get wrong. > > AFAIK the only reason vfio uses read/write for PCI was to avoid inventing > > a custom interface. But if you do, it looks like a set of ioctls would > > be much easier? You can even fit the existing uio infrastructure if you like. > > How would it be easier than producing/parsing a static data structure? > What would it look like? For example, for a property X, instead of adding a structure with identifier X, implement ioctl GET_X. Userspace calls this ioctl, an error implies the property is not present. > > Here's another idea: all the information is likely already available > > in sysfs. > > The only major thing that is likely available elsewhere is PCI config > space, and that was not new to this proposal. > Most other material is specifically related to the vfio/dtio interface > (e.g. offsets into the file handle, arguments to the "get irq fd" ioctl, > mapping of dtio regions/interrupts to device tree nodes), and could not > be "useful to more than just vfio". For example resources are already there in sysfs. > > A way to query where the device is in sysfs > > would give you *a ton* of information, including the type etc, > > For PCI, the user has domain/bus/dev/fn which should be sufficient to > find that, if desired. For device-tree devices, there's a device tree > path provided for each region/interrupt. > > -Scott So you are saying the user already has sysfs path? I thought the point was to pass all info through a single fd. -- 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
