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@xxxxxxxxxxxxxxxxxx> wrote: > > Arnd Bergmann [arnd@xxxxxxxx] wrote: > > | On Monday 05 July 2010, Albert Cahalan wrote: > > | > On Sun, Jul 4, 2010 at 7:39 PM, Matt Helsley <matthltc@xxxxxxxxxx> wrote: > > | > > On Sat, Jul 03, 2010 at 07:41:30PM -0400, Albert Cahalan wrote: > > | > >> <sukadev@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
