[lxc-devel] [RFC] Split liblxc and lxc-ui

[Andrian Nord]

> I wonder if this won't be the right approach for the capability drop
> as well. Instead of e.g. hardcode a default set into the lxc-start, 
> it could be really dump (like with my patch) when the drop list is
> just created by the lxc binary.

Having default in ui instead of library itself? It makes sense, as it
would be easier to document.

I suppose, it would be better (and much simplier) to read some supplied
config file always (e.g. located in /usr/share/lxc) to get defaults,
instead of hardcoding some defaults (as done in my capabilities
implementation). And this could be documented, and easily viewed. I still
insist, that config.include is useful and, practically, will allow admin
to override this defaults in per-group basis.

That is. As previous topics shows, not everybody from here want to have
full-featured lxc, and there is also some people, that want to. So, I
suppose, that there is a good time for splitting code on two parts -
bare system functions, that don't suppose any interaction with user and
user interface, that will supply end-user full-featured interface for
humans, not scripts.

How, imo, split should be done:
liblxc:
cgroups handling (cgroup.{c,h})

checkpoint/restart features (checkpoint.{c,h}, restart.{c,h},
	freezer.{c,h} - I suppose it's main it's usage)
configuration system based on supplied structure (conf.{c,h})
networking handling (*nl.{c,h}, network.{c,h})
namespaces handling (namespace.{c,h})
start/stop ({start,stop}.{c,h})

Command interface probably should be also kept inside library, but not
exported, to keep transport details in secret =), but some
cleanup/redesign could be done, as current implementation was written, I
suppose, for ui needs. For example, current state reporting technique
allows to have only one listener. If this interface would be kept inside
library, it would be very confusing, as it's not thread save, at least.
I suppose, command interface, that used to sync lxc-start and spawned
pre-exec process should be used to interact between hostspace and
containerspace. Hostspace than should call upper-package provided
callbacks to notify about events got. And this is problems of
upper-package how to export this information in common and thread-save
way - maybe via some kind of daemon.

I suppose, that current utilities should be kept, but with some design
changes to make them script-friendly at maximum, keeping, that
human-friendly interface would be provided by other implementation.

This is about code separation, not project - just move files for
liblxc and current ui implementation in different folders, making it
possible to build liblxc without ui.

P.S. error.c seems to be not used and not exported?