Drop IPC_OLD for direct ipc syscalls? (was: Re: [PATCH v2 3/4] m68k: Wire up direct ipc calls)

Drop IPC_OLD for direct ipc syscalls? (was: Re: [PATCH v2 3/4] m68k: Wire up direct ipc calls)

[Geert Uytterhoeven]

Hi Andreas,

On Thu, Sep 17, 2015 at 5:39 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> 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@linux-m68k.org

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

Re: Drop IPC_OLD for direct ipc syscalls?

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

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

If you wire up the direct ipc calls know you create an ABI that is
harder to get rid of.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Drop IPC_OLD for direct ipc syscalls?

[Geert Uytterhoeven]

Hi Andreas,

On Sun, Sep 20, 2015 at 12:38 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
>> 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?
>
> If you wire up the direct ipc calls know you create an ABI that is
> harder to get rid of.

That's what I was mostly worried about.
Thanks for confirming!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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