Re: [RFC PATCH 00/28] Linux Kernel Library

[Austin S Hemmelgarn]

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