[Devel] Re: [PATCH 11/11][v15]: Document sys_eclone

[Matt Helsley]

On Sun, Jul 11, 2010 at 05:00:10AM -0400, Albert Cahalan wrote:
> On Tue, Jul 6, 2010 at 6:25 PM, Sukadev Bhattiprolu
> <sukadev at linux.vnet.ibm.com> wrote:
> > Arnd Bergmann [arnd at arndb.de] wrote:
> > | On Monday 05 July 2010, Albert Cahalan wrote:
> > | > On Sun, Jul 4, 2010 at 7:39 PM, Matt Helsley <matthltc at us.ibm.com> wrote:
> > | > > On Sat, Jul 03, 2010 at 07:41:30PM -0400, Albert Cahalan wrote:
> > | > >> <sukadev at linux.vnet.ibm.com> wrote:

<snip>

> > | > You'd be copying from a struct in userspace to some random local
> > | > variables in the kernel. There is no reason why the kernel would
> > | > have to use a struct at all. You copy the flags, then see what else
> > | > you need to copy.
> > |
> > | Exactly. The size argument is also my main criticism of the suggested
> > | syscall, and I've been arguing the same as you.
> > |
> > | Note that you may still use copy the entire struct, provided that we
> > | leave enough reserved fields at the end for future extensions. If
> > | we run out of space ten years from now, we can still have a new syscall
> > | number with a new structure.
> >
> > If we need the API to be extendible, to me specifying the size in the
> > API seems more explicit than using the flags.
> 
> Is there any other system call with this sort of extendability?
> You're going against history and IIRC policy.
>
> Most explicit would be a version number, but even that is
> forbidden AFAIK.

Have a look at set_robust_list() -- it passes a size parameter for a
struct.

Lots of socket calls take a socklen_t for a variable-size address struct.
(Granted, they all go through socketcall, but that's a bit beside the
point.)

read() and write() syscalls operating on pseudofiles can be for structs
(e.g. signalfd_siginfo) and thus indirectly do this.

Cheers,
	-Matt Helsley
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers