Messages in this thread | | | Date | Thu, 23 Apr 2015 14:04:01 +0000 (UTC) | From | Mathieu Desnoyers <> | Subject | Re: [PATCH v16] sys_membarrier(): system-wide memory barrier (generic, x86) |
| |
----- Original Message ----- > On Fri, Apr 17 2015, Mathieu Desnoyers <mathieu.desnoyers@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
| |