[lxc-devel] [PATCH] extend command processor to handle generic data

[Serge Hallyn]

Quoting Dwight Engen (dwight.engen at oracle.com):
> On Tue, 21 May 2013 08:18:01 -0500
> Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> 
> > Quoting Dwight Engen (dwight.engen at oracle.com):
> > > Motivation for this change is to have the ability to get the
> > > run-time configuration items from a container, which may differ
> > > from its current on disk configuration, or might not be available
> > > any other way (for example lxc.network.0.veth.pair). In adding this
> > > ability it seemed there was room for refactoring improvements.
> > > 
> > > Genericize the command infrastructure so that both command requests
> > > and responses can have arbitrary data. Consolidate all commands
> > > into command.c and name them consistently. This allows all the
> > > callback routines to be made static, reducing exposure.
> > > 
> > > Return the actual allocated tty for the console command. Don't
> > > print the init pid in lxc_info if the container isn't actually
> > > running. Command processing was made more thread safe by removing
> > > the static buffer from receive_answer(). Refactored command
> > > response code to a common routine.
> > > 
> > > Signed-off-by: Dwight Engen <dwight.engen at oracle.com>
> > 
> > Working great on my box - thanks.
> > 
> > Acked-by: Serge E. Hallyn <serge.hallyn at ubuntu.com>
> > 
> > It seems like a general cleanup, but I'm wondering what your
> > motivation was for the get-config command?  Programs using the struct
> > lxc_container API or lua/python3 bindings can after all just do
> > 
> > 	import lxc
> > 	c = lxcContainer('c1', NULL);
> > 	c.get_config_item('lxc.rootfs')
> 
> Creating a container using the API/bindings creates a new c, and
> c->lxc_conf contains a parse of the on-disk configuration as it
> exists at the time of the lxcContainer() call but may not reflect an
> already running c1. I specifically wanted to know the veth pair name of
> an already running container, and I think it may be useful to know other
> configuration items of a running container which may differ from what
> is currently on disk.

Right, thanks.

-serge