On 09/02/2011 10:57 AM, Michael S. Tsirkin wrote: > 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. Why is this better? >>> 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. Their relationship to vfio regions, and their offsets in the fd, is not. >>> 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. No, as I understand it the point is to provide access through that fd, as well as information that is specific to that fd. Whether any particular extra bit of information gets included there is a question of convenience -- which should not be ignored in interface design. -Scott -- 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
