[Devel] Re: [PATCH 5/9] cr: capabilities: define checkpoint and restore fns

[Alexey Dobriyan]

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 at us.ibm.com> wrote:
> > Quoting Andrew G. Morgan (morgan at kernel.org):
> > ...
> >> > 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 at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers