This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [powerpc] Use DIRECT_SYSVIPC_SYSCALLS
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 10 Oct 2019 22:01:25 +0000
- Subject: Re: [PATCH] [powerpc] Use DIRECT_SYSVIPC_SYSCALLS
- Ironport-sdr: w1MKnDYPEG3VZ9CTSo9NwlhWNoG8OUlE3+Jt1siOC9OV6M+wk90VA6NFq6ffmUU1KvRJYhqxn+ 8iyIqnTdGFfH0SlFWBVYM4Da/KnDNNQpGOJg+Fa3zgyffmCcQMBL3jeNozp4bN4KC2eE+tT/aw gqVMa9aHPQF1UKIUPgrD+Wi1b468uwOABaQkQXsICdwJ2VhBvcuspTTwjOH/ISwstz8JjRn8tq hsAc+D0BymF8sgxuzRM206zFIkTE416hhTJP+xEK5helNPJQsSleJI1aerJp15Cq8WKnUjwpNS JzQ=
- Ironport-sdr: hI3HtpADSNB/N0ne/upOjCMvSV8srmwkmoqMq7QlEHU6CPwjJBjZND800Z9IU9OLiqP2yjkMJ2 DOxNc4+X+2DIvLJ1xS5LJSEtbuv68VA6FUVRpMredDFufuptC1RzmjOuRugnfx1W4Kblwc3HyR YLK0XWu4c70BZS6lQx3fkXlp6FNQutRsUVb+vKNaTVAR+U7Oq4ZnmrUxjImSUvxHo83P5Fl5RP j5TgJZkMwG4Lpw/NCeYwEdYEifR+NvXswefukdgWSAKI1hbAUHIXxanAT+zPlty7p6VnV2dMBI /8I=
- References: <1570663013-10269-1-git-send-email-pc@us.ibm.com> <875zkxt9pk.fsf@oldenburg2.str.redhat.com> <8b82e568-52e7-c79a-3383-6d6a06a1e3a0@linaro.org>
On Thu, 10 Oct 2019, Adhemerval Zanella wrote:
> As you have pointed out, tying up wire-up semop with __NR_semop
> definition might indeed create a wrong build. For this case I
> would prefer to instead of a sysdep override to do something as below:
>
> --
> #__ASSUME_DIRECT_SYSVIPC_SYSCALLS
> # ifdef __NR_semop
> int res = INLINE_SYSCALL_CALL (semop, semid, sops, nsops);
> if (ret >= 0 || errno != ENOSYS)
> return ret;
If __ASSUME_DIRECT_SYSVIPC_SYSCALLS does not imply presence of the semop
syscall, that should be made clear in the comment on the default
definition. If in addition the semop syscall might be added on
architectures that do define __ASSUME_DIRECT_SYSVIPC_SYSCALLS but don't
currently define semop, to me that indicates a separate
__ASSUME_SEMOP_SYSCALL is needed. (Note how we have lots of separate
__ASSUME_* macros for socket syscalls, which avoids such complications in
using a macro that's supposed to relate to lots of syscalls that aren't
all present together.)
--
Joseph S. Myers
joseph@codesourcery.com