On Wed, Nov 4, 2015 at 3:50 PM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > On Wed, Nov 04, 2015 at 01:24:03AM +0200, Octavian Purdila wrote: >> Thanks for the pointers Richard, I am going to take a look at it. > > Now I've had a chance to look at some of the example LKL tools, here's > what this actually involves. It's not actually a great deal of work, > it could probably be done in a day or two, but see my question about > `lkl_sys_*' below. > > libguestfs (the library part) needs to talk over an RPC connection to > its daemon. See diagram here: > > http://libguestfs.org/guestfs-internals.1.html > > The code in src/launch-{direct,libvirt,uml,...}.c sets up that > connection and runs the daemon -- normally inside a qemu wrapper, but > it could be inside UML. For LKL I think it should just fork the > daemon directly. > > The daemon would then be linked to LKL. > > So really what's needed is a src/launch-lkl.c probably modelled after > one of these current backends: > > https://github.com/libguestfs/libguestfs/blob/master/src/launch-uml.c > https://github.com/libguestfs/libguestfs/blob/master/src/launch-unix.c > > and then recompile the daemon to link to LKL: > > https://github.com/libguestfs/libguestfs/tree/master/daemon > > and pass the list of disk images to the daemon, probably best to do > that on the guestfsd command line. > > My only problem here: you can't just link to daemon to LKL, do you > have to change all of the system calls from `foo' to `lkl_sys_foo'? > That's an awful lot of #ifdefs ... > We could redefine the syscalls/libc symbols to call lkl_sys_ functions in launch-lkl, e.g.: int opendir(const char *path) { return lkl_opendir(new_path) } -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
