[Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver

[Cam Macdonell]

On Mon, Mar 29, 2010 at 2:59 PM, Avi Kivity <address@hidden> wrote:
> On 03/28/2010 10:48 PM, Cam Macdonell wrote:
>>
>> On Sat, Mar 27, 2010 at 11:48 AM, Avi Kivity<address@hidden>  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.
>
>