From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: Most up to date blktap2 kernel driver Date: Thu, 22 Sep 2011 10:59:43 +0200 Message-ID: References: <1316677231.23371.7.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1316677231.23371.7.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org > I was just wondering about this, is your plan to bolt a block frontend > onto the existing tapdisk2 process or are you building a thing using a > NetBSD library for doing block devices in userspace (I think you are > doing the former but either you or Christoph mentioned that library > thing at one point too). Well, my first try was to create a user-space implementation of the block devices found in blktap, so there was no need to change the current blktap tools. This is however not possible right now, because the library for implementing block and char devices as user-space daemons doesn't support mmap, and there's no clear way about how to implement this. Correct me if I'm wrong, but the second option would be to directly implement the I/O ring from user-space without using any devices, I haven't had much time to look into this, but I think this is the best way, because it doesn't involve the constant context changes that the implementation explained before has. I hope that looking into qemu disk backend file can provide me with some information about how to do this, possibly using libxc? > The former plan would be awesome since it would make this work useful on > all platforms and not just NetBSD. As you've no doubt noticed the > blktap2 kernel side isn't (and won't be) in Linux upstream either. > > Ian.