Closed jonludlam closed 10 years ago
Made this PR as a bit of an RFC. It's very helpful if we want to get the xenserver buildroot project working on the cubies.
I think it would be better to have a git tree with this patch merged in, rather than the patches inline here. The current tree is just upstream Linux -- is there any upstreaming going on for blktap?
IIRC there's no plan to upstream the code because it would be better to replace it with a fully userspace backend (such as qemu qdisk). This code is useful only in the meantime-- we should chuck it when the userspace backends work better. However it might take a while to get the userspace backends working well enough.
On Tue, Aug 19, 2014 at 7:43 PM, Anil Madhavapeddy <notifications@github.com
wrote:
I think it would be better to have a git tree with this patch merged in, rather than the patches inline here. The current tree is just upstream Linux -- is there any upstreaming going on for blktap?
— Reply to this email directly or view it on GitHub https://github.com/mirage/xen-arm-builder/pull/25#issuecomment-52679986.
Dave Scott
Yes; this is a temporary workaround until we can replace blktap with some other storage solution. This is likely to be the long term plan in XenServer too, but there's a lot invested in blktap and it's not going to be a quick job to replace it (years?).
In the medium term (months?), we'll likely have something we can use for local storage suitable for the cubies (e.g. Dave's ezlvm), but with this patch we can use xenserver-core with the cubies today.
Ok. I'm happy for this to go in since it doesn't affect the usual blkback that's used. Convenience is, after all, the entire point of this image builder.
This allows us to use blktap2.5 and therefore get decent copy-on-write disks via VHDs (see http://github.com/xapi-project/blktap)
Signed-off-by: Jon Ludlam jonathan.ludlam@citrix.com