----- Original Message ----- > On Fri, Apr 17 2015, Mathieu Desnoyers <mathieu.desnoy...@efficios.com> > wrote: > > > + */ > > +SYSCALL_DEFINE2(membarrier, int, cmd, int, flags) > > +{ > > + switch (cmd) { > > + case MEMBARRIER_CMD_QUERY: > > + return MEMBARRIER_CMD_BITMASK; > > + case MEMBARRIER_CMD_SHARED: > > + if (num_online_cpus() > 1) > > + synchronize_sched(); > > + return 0; > > + default: > > + return -EINVAL; > > + } > > +} > > Shouldn't flags be enforced 0, to actually make future extensions > possible without risk of breaking some sloppy userspace? I think that is > or should be part of "make sure new syscalls take a flags parameter".
Very good point! I will update the code to check this, and the documentation, with the wording: (in membarrier.c:) "@flags: Currently needs to be 0. For future extensions." (in man page) "The flags argument needs to be 0. For future extensions." > > > + * If this system call is not implemented, -ENOSYS is returned. If the > > + * command specified does not exist, or if the command argument is > > invalid, > > + * this system call returns -EINVAL. For a given command, this system call > > + * is guaranteed to always return the same value until reboot. > > I like that guarantee, but it may be a bit much to promise for any and > all possible future flags. So maybe weaken it to 'For a given command > and flags==0, this ...'. This makes tons of sense, updating the doc with this too, with the wording: "For a given command, with flags argument set to 0, this system call is guaranteed to always return the same value until reboot." Thanks! Mathieu > > > Rasmus > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/