Quoting Oren Laadan (orenl@xxxxxxxxxxx):
>
>
> Matt Helsley wrote:
> > On Wed, Oct 21, 2009 at 07:51:57PM -0500, Serge E. Hallyn wrote:
> >> Quoting Oren Laadan (orenl@xxxxxxxxxxx):
> >
> > <snip>
> >
> >>>> More practically, requiring userspace to pass over a flag
> >>>> consisting of CKPT_DBG_MEM|CKPT_DBG|FILE|CKPT_DBG|TASK, and
> >>>> handle corresponding usage flags, is not nice.
> >>> I agree with you on about this. Maybe we want a better
> >>> interface ?
> >>>
> >>> Which brings me to this random thought: maybe we want to
> >>> make the fourth argument of sys_{checkpoint,restart} a
> >>> structure, to make it easier to extend it in the future
> >>> without having to go throw a clone3-like hell...
> >
> > Adding new kernel interfaces is supposed to be somewhat hellish.
> >
> >>> Specifically, this structure could now be:
> >>>
> >>> struct ckpt_args {
> >>> int version;
> >>> int logfd;
> >>> int logmask;
> >>> };
> >>>
> >>> (or use union checkpoint {} and union restart {} to tell
> >>> between checkpoint- and restart-related args.
> >> Well I don't like passing structs to the kernel actually (and
> >
> > Let's not do this. I agree that passing structs, when unnecessary,
> > is gross. Especially if it gets used to extend the arguments
> > passed via the syscall interface (new flag values I don't mind).
>
> Ok, we already allow future extension by being strict about
> which flags are taken or not.
>
> Then what do we do with logmask ? I prefer it to be a per-syscall
> value as opposed to a system-wise setting.
Getting ugly but...
if we were to use tracepoints, then we could (or the admin could) have the
function which is loaded determine based on a task's cgroup what to
print out.
I did say it was ugly...
-serge
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
