On Sat, Jun 06, 2009 at 08:02:28AM -0700, Andrew G. Morgan wrote:
> On Fri, Jun 5, 2009 at 12:41 PM, Serge E. Hallyn <serue@xxxxxxxxxx> wrote:
> > Quoting Andrew G. Morgan (morgan@xxxxxxxxxx):
> > ...
> >> > Now you mention using kernel_cap_t's... we can go partway
> >> > down that road, but the inherent problem is serializing the
> >> > relevant data so it can be streamed to some file. So I
> >> > think it's better if the subsystems are required to specify
> >> > a useful format (like struct ckpt_capabilities) and define
> >> > the checkpoint/restart helpers to serialize data into the
> >> > struct. We can try and get cute with dual mirrored
> >> > struct defs, one which is defined in terms the caps code
> >> > can understand, and one defined in more arch-independent
> >> > terms (which is why we need __u64s and packed, for instance).
> >> > But that seems more fragile than having clear and simple
> >> > requirements for the $SUBYSTEM_checkpoint() and $SUBSYSTEM_restart()
> >> > helpers.
> >>
> >> I like this $SUBSYSTEM_checkpoint() etc. thing.
> >>
> >> I like the ckpthdr.sed thing. I think a similar rule could be used to
> >> generate the calls to the list of $SUBSYSTEM_checkpoint() functions.
> >
> > Sorry, I don't follow. Could you say a bit more about this?
>
> See sketch below.
>
> >
> >> For serialization, could a kernel "gcc -E checkpoint-headers.h >
> >> this-kernel-checkpoint-file.h" build rule be enough?
> >
> > Again, I don't follow. Do you mean to turn something like kernel_cap_t
> > into something like struct ckpt_capabilities?
>
> Yes, but without manual effort.
>
> To return the the 1,2,3 breakdown. I think it should be possible for 1
> to provide code like this:
>
> $SUBSYSTEM_header.h:
> struct ckpt_$SUBSYSTEM_s {
> kernel_foo_t a, b, c;
> };
>
> $SUBSYSTEM_code.c:
> void $SUBSYSTEM_checkpoint(struct *storage_ptr)
> {
> }
>
> int $SUBSYSTEM_restore(struct *storage_ptr)
> {
> }
This doesn't work. Kernel internals don't have clearly defined subsystem boundaries,
capabilities or not.
As for capabilities, I think code below is everything what's needed:
typedef __u64 kstate_cap_t;
struct kstate_image_cred {
...
kstate_cap_t cap_inheritable;
kstate_cap_t cap_permitted;
kstate_cap_t cap_effective;
kstate_cap_t cap_bset;
...
};
static void dump_capabilities(kstate_cap_t *i, kernel_cap_t *cap)
{
BUILD_BUG_ON(sizeof(kstate_cap_t) != sizeof(kernel_cap_t));
memcpy(i, cap, sizeof(kstate_cap_t));
}
Kernel and userspace can do anything they want with such image easily.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
