On Mon, Mar 29, 2010 at 2:59 PM, Avi Kivity <avi@xxxxxxxxxx> wrote: > On 03/28/2010 10:48 PM, Cam Macdonell wrote: >> >> On Sat, Mar 27, 2010 at 11:48 AM, Avi Kivity<avi@xxxxxxxxxx> wrote: >> >>> >>> On 03/26/2010 07:14 PM, Cam Macdonell wrote: >>> >>>> >>>> >>>>> >>>>> I'm not familiar with the uio internals, but for the interface, an >>>>> ioctl() >>>>> on the fd to assign an eventfd to an MSI vector. Similar to ioeventfd, >>>>> but >>>>> instead of mapping a doorbell to an eventfd, it maps a real MSI to an >>>>> eventfd. >>>>> >>>>> >>>> >>>> uio will never support ioctls. >>>> >>> >>> Why not? >>> >> >> Perhaps I spoke too strongly, but it was rejected before >> >> http://thread.gmane.org/gmane.linux.kernel/756481 >> >> With a compelling case perhaps it could be added. >> > > Ah, the usual "ioctls are ugly, go away". > > It could be done via sysfs: > > $ cat /sys/.../msix/max-interrupts > 256 > $ echo 4 > /sys/.../msix/allocate > $ # subdirectories 0 1 2 3 magically appear > $ # bind fd 13 to msix > $ echo 13 > /sys/.../msix/2/bind-fd > $ # from now on, msix interrupt 2 will call eventfd_signal() on fd 13 > > Call me old fashioned, but I prefer ioctls. Good point. iiuc, the goal relative to ioctls in UIO was to not have device drivers creating their own device-specific ABIs and drivers that are just massive switch statements. Having ioctls that support functions for UIO in general, such as pairing msi vectors to eventfds, does not go against that goal. > > -- > Do not meddle in the internals of kernels, for they are subtle and quick to > panic. > > -- 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
