From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nvppg-00034L-VL for qemu-devel@nongnu.org; Sun, 28 Mar 2010 06:35:05 -0400 Received: from [140.186.70.92] (port=32797 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nvppf-00033d-9G for qemu-devel@nongnu.org; Sun, 28 Mar 2010 06:35:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nvppd-00027n-LB for qemu-devel@nongnu.org; Sun, 28 Mar 2010 06:35:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64661) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nvppd-00027c-DY for qemu-devel@nongnu.org; Sun, 28 Mar 2010 06:35:01 -0400 Date: Sun, 28 Mar 2010 13:31:23 +0300 From: "Michael S. Tsirkin" Message-ID: <20100328103123.GC21749@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> <20100328074754.GA21749@redhat.com> <4BAF0D03.7060300@redhat.com> <20100328094006.GB21749@redhat.com> <4BAF251E.50609@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BAF251E.50609@redhat.com> 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: Cam Macdonell , qemu-devel@nongnu.org, kvm@vger.kernel.org On Sun, Mar 28, 2010 at 12:45:02PM +0300, Avi Kivity wrote: > On 03/28/2010 12:40 PM, Michael S. Tsirkin wrote: >>>> uio accepts 32 bit writes to the char device file. We can encode >>>> the fd number there, and use the high bit to signal assign/deassign. >>>> >>>> >>> Ugh. Very unexpandable. >>> >> It currently fails on any non-4 byte write. >> So if we need more bits in the future we can always teach it >> about e.g. 8 byte writes. >> >> Do you think it's worth it doing it now already, and using >> 8 byte writes for msi mapping? >> > > Aren't ioctls a lot simpler? > > Multiplexing multiple functions on write()s is just ioctls done uglier. I don't have an opinion here. Writes do have an advantage that strace can show the buffer content without being patched. Further, something along the lines proposed above means that we do not need to depend in a system header to get the functionality. > -- > error compiling committee.c: too many arguments to function