Hi Andreas,
On Thu, Sep 17, 2015 at 5:39 PM, Andreas Schwab <schwab@xxxxxxxxxxxxxx> wrote:
Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> writes:
It would be nice if the direct syscalls would drop the use of
ipc_parse_version. Currently, apart from going through the ipc
multiplexer, the semctl, shmctl and msgctl wrappers in libc need to add
the IPC_64 bit to the cmd operand. If that would be implied then no
special wrappers would be needed any more for direct syscalls.
You mean that we should drop "select ARCH_WANT_IPC_PARSE_VERSION",
but we can't do that because an indirect call through sys_ipc() would
still need it when dispatching to sys_{sem,shm,msg}ctl()?
Yes. But all architectures that currently use both sys_ipc and
ARCH_WANT_IPC_PARSE_VERSION would benefit from decoupling it when they
add the direct syscalls.
Do we currently have architectures that use both sys_ipc and the direct
syscalls, where keeping ipc_parse_version() in the direct syscalls is
required?
IMHO it doesn't make sense to suport IPC_OLD via the direct syscalls,
even for those architectures that started with them in the first place.
There are quite a few architectures that define
ARCH_WANT_IPC_PARSE_VERSION even though they started life after IPC_64
was added. They probably just forgot to adjust ipc/util.h back then.
Thanks!
I had a quick look at the code, but I'm not feeling sufficiently familiar with
the (g)libc interaction to cook up a patch dropping ipc_parse_version() from
direct ipc calls.
Should I postpone wiring up the direct ipc syscalls on m68k (and thus renumber
__NR_membarrier) until the above is resolved, or can they go in in v4.3?
I guess the same is true for x86-32.
Thanks again!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
