----- 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/
