On 2015-11-03 18:24, Octavian Purdila wrote:
On Wed, Nov 4, 2015 at 12:45 AM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote:I'm dubious that a lib-based approach could support LVM, partioning, ntfs-3g, qcow2, vmdk and all the other libguestfs stuff that relies on userspace tools + qemu as well as just the kernel drivers. Nevertheless a fast subset of libguestfs supporting just kernel filesystem drivers could be useful.LKL uses the full Linux I/O stack and I think LVM and partitioning should work out of the box. Adding support for qcow2 and vmdk should be possible as well. ntfs-3g might be problematic.
Partitioning will work fine based on what you say. MD using the old metadata and automatic assembly should also work fine (assuming there is some way to tell the library to simulate running initcalls). DM (and by extension LVM, which is a bunch of userspace stuff on top of regular DM) and new style MD both require userspace tools to configure and interact with, this could be handled in two different ways:
1. Update the LVM and MD tools so they can be built as libraries and work directly with LKL. 2. Provide some wrapper functions to emulate dmsetup, lvm, and mdadm as distinct library calls.Of these, the first option is likely to be the best for long-term support, but the second is probably going to be easier to code quickly.
QCOW2 and VMDK are both VM disk formats, and while I would love to see a driver treat them (and VDI, and VHD) like regular disk images on Linux in general, that will take some effort to implement properly.
NTFS-3G is a FUSE based filesystem driver, so that kind of functionality would probably need to be implemented in the application itself (although having some way to have the app just link to it instead would be absolutely wonderful).
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
