[cut] > > So overall the interface and extension makes sense. My only question is > > whether it's better to get complete reuse out of GET_REGION_INFO and > > GET_IRQ_INFO and then add another device tree specific ioctl or is it > > better to add a device tree index and path to the existing GET_*_INFO > > ioctls? Getting some information from one ioctl and passing pieces of > > it back to another ioctl feels a little clunky. > > > > I thing at this point we should clearly separate the info we need to > pass for the core functionality (assigning the device's resources), > and the information we want to pass in order to generate a guest DT. > For ARM a DT is not generated by QEMU yet, but instead a proper DTB > needs to be passed by the user (granted, this will not be the case for > ever). So I think even if we treat them the same in code, we should be > discussing them separately. We do need to keep core resources separate from what it takes to generate a guest DT, but note the purpose of the devtree info is not primarily to help generate a guest DT. User space (not just QEMU) needs to know what the regions and interrupts advertised by DEVICE_GET_INFO correspond to. If there are 4 interrupts and 2 register regions, how does user space know the purpose/function of each? Apart from something like the devtree info I don't see how a user space driver can know how to use the regions and interrupts. The kernel is not guaranteeing any particular ordering of resources. So in the DMA engine example I gave, the devtree info let's user space know which interrupt corresponds to which DMA channel. QEMU is a special case in that it is going to expose the device to a virtual machine and needs to generate a normal device tree node...but that is a separate problem that needs to be solved in QEMU. Stuart -- 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
