> This RFC's intention is to show what an interface to access device node > properties for VFIO_PLATFORM can look like. > > If a device tree node corresponding to a platform device bound by > VFIO_PLATFORM > is available, this patch series will allow the user to query the properties > associated with this device node. This can be useful for userspace drivers > to automatically query parameters related to the device. > > An API to return data from a device's device tree has been proposed before on > these lists. The API proposed here is slightly different. > > Properties to parse from the device tree are not indexed by a numerical id. > The host system doesn't guarantee any specific ordering for the available > properties, or that those will remain the same; while this does not happen in > practice, there is nothing from the host changing the device nodes during > operation. So properties are accessed by property name. > > The type of the property accessed must also be known by the user. Properties > types implemented in this RFC: > - VFIO_DEVTREE_ARR_TYPE_STRING (strings sepparated by the null character) > - VFIO_DEVTREE_ARR_TYPE_U32 > - VFIO_DEVTREE_ARR_TYPE_U16 > - VFIO_DEVTREE_ARR_TYPE_U8 > > These can all be access by the ioctl VFIO_DEVICE_GET_DEVTREE_INFO. A new ioctl > was preferred instead of shoehorning the functionality in > VFIO_DEVICE_GET_INFO. > The structure exchanged looks like this:
You'll have to forgive my ignorance on the history. But with the dtc tool already supporting a filesystem representation (--in-format=fs), with the dtc tool source already built into qemu, and having an example implementation of such an interface in /proc/device-tree/ why is an ioctl interface preferred over a filesystem interface? -- 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
