Daniel Lezcano [dlezcano@xxxxxxxxxx] wrote:
> Sukadev Bhattiprolu wrote:
>> Pls let me know if this will work. Will address your other comments
>> and repost entire patchset.
>>
>> ---
>> From: Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx>
>> Date: Wed, 24 Mar 2010 17:26:44 -0700
>> Subject: [PATCH 1/1] Add --with-usercr configure option
>>
>> Add a configure option, --with-usercr=dir which would allow linking
>> with external (i.e USERCR) implementation of checkpoint/restart.
>>
>> For now, USERCR "publishes" a app-checkpoint.h, checkpoint.o and
>> restart.o files which implement the functions app_checkpoint() and
>> app_restart().
>>
>> Usage:
>> $ ./autogen.sh
>>
>> $ ./configure --help |grep usercr
>> --with-usercr=dir use the Checkpoint/Restart implementation in 'dir'
>
> Ok, let's call it : --with-cr
Ok, or how about --with-libcr given that it will eventually be a library.
>
>> $ ls /home/guest/user-cr/
>> app-checkpoint.h checkpoint.o restart.o
>>
>> $ ./configure --with-usercr=/home/guest/user-cr
>>
>> TODO:
>> If names of interfaces in USERCR change, we may want to rename
>> the config option too ?
>>
>> Can we remove the src/lxc/{checkpoint.o,restart.o} files from
>> liblxc.so and lxc-checkpoint/lxc-restart directly with them ?
>> That way, the USERCR interfaces/object files don't end up in
>> liblxc.so.
>>
>> USERCR_CFLAGS are only needed for src/lxc/{checkpoint.c,restart.c}
>> but not sure if there is an easy way to define autoconf CFLAGS
>> just for those two files.
>
> Hum, no. It would be preferable to integrate them in lxc for now (as
> experimental code) and later create a glue between lxc and usercr, so
> usercr interfaces would be callable as a plugin of lxc.
>
> The --with-cr will remains but specifying a CR library. The lxc
> checkpoint and restart code will then dlopen this library and use the
> checkpoint / restart functions of this library.
>
> If no library is specified, the lxc-checkpoint / lxc-restart will return
> ENOSYS.
>
> That will ensure the CR specific code stays in a separate library and
> will keep things opened to take into account other CR solutions like
> blcr.
>
> But until we reach this point, we should integrate everything hardcoded
> in the lxc library in order to let the plugin API drawing to appear in
> the integration big picture.
Ok. Sounds good. I will leave the USERCR interfaces in liblxc.so for now.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
