From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] Blktap: Userspace file-based image support. (RFC) Date: Mon, 19 Jun 2006 14:51:04 -0500 Message-ID: <44970028.4080205@us.ibm.com> References: <4496F30E.6020006@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andrew Warfield Cc: Xen Developers , Julian Chesterfield List-Id: xen-devel@lists.xenproject.org Andrew Warfield wrote: >> A very much like the idea of a userspace block device backend. Have you >> considered what it would take to completely replace blkback with a >> userspace backend? I'm also curious why you choose a character device >> to interact with the ring queue instead of just attaching to the ring >> queue directly in userspace. > > Oops (again), missed answering your char device question. We just use > a char device to pin up a region of virtual address space for each > disk as it's presented in userspace. Is this strictly needed though? My current understanding (which may be totally off) of this device is that it contains: - first page is ring/queue - rest of file is mmap()'able and as requests come in over the blkfront queue, you map them into that address space - poll/ioctl is used for event channel notification Couldn't you do all of this in pure userspace though with privcmd and evtchn? Regards, Anthony Liguori > Anyone familiar with blkback > will recognise the technique. In our case, the first page is a > request/response ring between tap driver and application, and the > remainder is a sparsely populated address space where data pages are > mapped as they fly through. We signal down with ioctl()s, and up > using poll(). > > a.