[lxc-devel] Question about a "real" LXC library

[Serge Hallyn]

Quoting Jon Taylor (dosadi82 at gmail.com):
> Hi,
> 
> I was initially working with libvirt, but all I was doing was calling out
> to lxc so I decided to ditch libvirt and work directly with LXC since the
> current libvirt is a bit buggy for me.  To that end, I have been playing
> with and studying LXC, and I have a question.  I was wondering why liblxc
> is designed to call a lot of command-line utilities using system(), instead
> of the other way around.  AFAIK, it is more correct to put standard
> functionality in a standard library and then write code which uses the
> library-exposed APIs.  IMHO, liblxc should directly hit the Linux kernel
> APIs, and the lxc-* command line utilities should dlopen() liblxc.so.
> 
> Not being able to statically link everything needed to run LXC containers
> into one binaryanlong with my program code is a real showstopper for me - I
>  need to be able to boot Linux from flash, run my master process in place
> of init, and spawn hundreds if not thousands of threads, each with its own
> virtual networking setup.  I am reluctant to dissect the lxc-* command line
> utility code and import it into my codebase for reasons of maintainability.
>  Am I missing something somewhere?  Has anyone else here ever used LXC
> containers in an embedded environment?

See /usr/include/lxc/lxccontainer.h for the 'real' lxc library, which is
still being developed.  It still has to shell out for some things, like
zfs device handling, and it will always call out to the templates to
fill in new container root filesystems (though you can compile your own
templates as c code if you like).  But many of the shell scripts are
being replaced by c code and exported to lua/python3/go.