From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nwcnn-00044Y-V7 for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:52:24 -0400 Received: from [140.186.70.92] (port=50774 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nwcnm-0003zt-0H for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:52:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nwcnh-00051h-Pc for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:52:21 -0400 Received: from mail-iw0-f194.google.com ([209.85.223.194]:43452) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nwcnh-00051D-Kv for qemu-devel@nongnu.org; Tue, 30 Mar 2010 10:52:17 -0400 Received: by iwn32 with SMTP id 32so200400iwn.18 for ; Tue, 30 Mar 2010 07:52:15 -0700 (PDT) MIME-Version: 1.0 Sender: camm@ualberta.ca In-Reply-To: <4BB114AC.9040902@redhat.com> References: <1269497376-21903-1-git-send-email-cam@cs.ualberta.ca> <4BAB30EE.4020509@redhat.com> <8286e4ee1003250924q7cca5e71u8b8b7c6d8b785eb8@mail.gmail.com> <4BAB90BB.5030401@redhat.com> <8286e4ee1003260914u5e6ceee2pf0c00590de182fb6@mail.gmail.com> <4BAE44F2.20801@redhat.com> <8286e4ee1003281248k204a5bd4tc48e6ccc755918b@mail.gmail.com> <4BB114AC.9040902@redhat.com> Date: Tue, 30 Mar 2010 08:52:14 -0600 Message-ID: <8286e4ee1003300752n41a5afdbta0b23fc0cb75b99d@mail.gmail.com> From: Cam Macdonell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, "Michael S. Tsirkin" On Mon, Mar 29, 2010 at 2:59 PM, Avi Kivity wrote: > On 03/28/2010 10:48 PM, Cam Macdonell wrote: >> >> On Sat, Mar 27, 2010 at 11:48 AM, Avi Kivity =A0wrote: >> >>> >>> 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. =A0Similar to ioeven= tfd, >>>>> 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: > > =A0$ cat /sys/.../msix/max-interrupts > =A0256 > =A0$ echo 4 > /sys/.../msix/allocate > =A0$ # subdirectories 0 1 2 3 magically appear > =A0$ # bind fd 13 to msix > =A0$ echo 13 > /sys/.../msix/2/bind-fd > =A0$ # 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. > >