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

Daniel Lezcano dlezcano at fr.ibm.com
Sun Jan 10 05:17:09 UTC 2010


Andrian Nord wrote:
>> 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.

So if I understand correctly, you wish to create a new component which 
is a full featured system container. For that you need to re-organize 
the code in liblxc, correct ?

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

it is used in start.c and lxc_init.c






More information about the lxc-devel mailing list