From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Most up to date blktap2 kernel driver Date: Thu, 22 Sep 2011 10:10:37 +0100 Message-ID: <1316682637.23371.45.camel@zakaz.uk.xensource.com> References: <1316677231.23371.7.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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: Roger Pau =?ISO-8859-1?Q?Monn=E9?= Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Thu, 2011-09-22 at 09:59 +0100, Roger Pau Monné wrote: > > 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. Right. And that would be very OS specific I guess? > 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, Yes, that is what I was suggesting. I think we generally have consensus that this is the right direction to take blktap. > 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? Using libxc would be better than using the OS provided interfaces directly since it abstracts out the differences between the ioctls/devices on different OSs. > > > 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.