Hello, On Wed, May 06, 2015 at 03:27:54PM +0100, George Dunlap wrote: > On Tue, May 5, 2015 at 2:07 PM, Johnny Hughes <johnny at centos.org> wrote: > > WRT a new kernel .. the 3.18.x kernel has been selected to be maintained > > as an LTS until Jan 2017. I think we should start work on rebuilding > > this kernel and using it in the x4c projects. > > > > https://lwn.net/Articles/636289/ > > > > Thoughts? > > > > I will grab this kernel and try to roll in all the patches, etc. and see > > if I can make it work. > > I did a little bit of work on building the 3.18 kernel a couple of > weeks ago, but it looks like the blktap2.5 kernel code we were using > before has totally bitrotted. > > I see three ways forward: > > 1. Try to do a "deep port" of the functionality, continuing to > maintain it going forward. > How badly has the blktap 2.5 kernel code bitrotted? What areas are the most problematic? Any idea how much work would it be to get it working with 3.18 LTS ? > 2. Start using the blktap3 code, which requires no kernel driver. > > 3. Drop blktap support, and ask people to use qdisk for vhd. > > Re #1, I'm not really excited about the idea of trying to keep porting > those patches forward (and finding and fixing bugs in the forward-port > each time). > > Re #2, this would require getting the blktap3 stuff working upstream > and then backporting it. > Yeah.. likely more work than the "deep port" of blktap 2.5 kernel code.. > #3 would be by far the easiest. > But not very nice.. > In parallel to the Xen for C7 work I've been doing, I've been working > on getting upstream Xen to build against XenServer's blktap code, with > then aim of moving to blktap3. If we want to go with #2, then a major > kernel update will have to wait until that work is done. > > -George Thanks, -- Pasi