This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Stepan, > Resending as this was truncated yesterday. > > 31.05.2019 в 14:49:02 +0400 Stepan Golosunov написал: > > 30.05.2019 в 16:01:12 +0000 Joseph Myers написал: > > > On Wed, 29 May 2019, Lukasz Majewski wrote: > > > > > > > List of new syscalls added to v5.1. kernel (they accept data > > > > based on struct timespec and timeval with 64 bit tv_sec): > > > > > > > > clock_gettime64 > > > > clock_settime64 > > > > clock_adjtime64 > > > > clock_getres_time64 > > > > clock_nanosleep_time64 > > > > timer_gettime64 > > > > timer_settime64 > > > > timerfd_gettime64 > > > > timerfd_settime64 > > > > utimensat_time64 > > > > pselect6_time64 > > > > ppoll_time64 > > > > io_pgetevents_time64 > > > > recvmmsg_time64 > > > > mq_timedsend_time64 > > > > mq_timedreceive_time64 > > > > semtimedop_time64 > > > > rt_sigtimedwait_time64 > > > > futex_time64 > > > > sched_rr_get_interval_time64 > > > > > > I do *not* think semtimedop_time64 should be included in the set > > > of syscalls. I think that if the macro is defined on systems > > > with __WORDSIZE == 64, it should *only* relate to syscalls where > > > the syscall semantics are *identical* for both the old syscall > > > (on systems where __WORDSIZE or __SYSCALL_WORDSIZE is 64) and for > > > the new one, so that no code will ever have to handle the two > > > syscalls differently. And the comment should explicitly say that > > > it is only for that subset of syscalls. > > > > There is already a macro to specify whether semtimedop semantics is > > available: __ASSUME_DIRECT_SYSVIPC_SYSCALLS. It should be always > > defined for 5.1+ kernels. (Lack of support for > > __NR_semtimedop_time64 in glibc is one of the obstacles in the way > > of defining __ASSUME_DIRECT_SYSVIPC_SYSCALLS currently.) > > > > I see how splitting semtimedop/semtimedop_time64 > > availability from __ASSUME_DIRECT_SYSVIPC_SYSCALLS can help to > > untangle __ASSUME_DIRECT_SYSVIPC_SYSCALLS from time64. (It would > > probably be overkill though—in the end splitted macro would be > > defined exactly at the same time as > > __ASSUME_DIRECT_SYSVIPC_SYSCALLS.) Please correct me if I'm wrong: 1. As we discussed the __ASSUME_TIME64_SYSCALLS is supposed to indicate 64 bit time support in a way that syscall ABI is the same for old and new syscalls (there is no need to add any extra code in handling them). 2. The new syscalls - like semtimedop_time64, which need extra code for handling, shall be excluded from __ASSUME_TIME64_SYSCALLS and hence would receive new flag(s) - as proposed: __ASSUME_SEMTIMEDOP_TIME64 > > > > I fail to see how not using __ASSUME_TIME64_SYSCALLS can add > > anything but extra complexity into the following logic: Could you be more specific here (or rephase the above sentence)? > > __ASSUME_SEMTIMEDOP_TIME64 > > defined __ASSUME_TIME64_SYSCALLS > > && defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS > > && defined __NR_semtimedop_time64: > > call semtimedop_time64 > > > > defined __ASSUME_TIME64_SYSCALLS > > && defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS > > && !defined __NR_semtimedop_time64: > > call semtimedop > > > > defined __ASSUME_TIME64_SYSCALLS > > && !defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS: > > (must not happen when __LINUX_KERNEL_VERSION >= 0x050100) > > call ipc with IPCOP_semtimedop > > > > !defined __ASSUME_TIME64_SYSCALLS > > && defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS: > > try __NR_semtimedop_time64, fallback to 32-bit semtimedop > > > > !defined __ASSUME_TIME64_SYSCALLS > > && !defined __ASSUME_DIRECT_SYSVIPC_SYSCALLS: > > try __NR_semtimedop_time64, fallback to 32-bit ipc with > > IPCOP_semtimedop Now at sysdeps/unix/sysv/linux/semtimedop.c we do have: #ifdef __ASSUME_DIRECT_SYSVIPC_SYSCALLS return INLINE_SYSCALL_CALL (semtimedop, semid, sops, nsops, timeout); #else return INLINE_SYSCALL_CALL (ipc, IPCOP_semtimedop, semid, SEMTIMEDOP_IPC_ARGS (nsops, sops, timeout)); #endif And yes, this code would be more complicated when we follow the conversion paradigm described here: https://www.gnu.org/software/libc/manual/html_mono/libc.html#g_t64_002dbit-time-symbol-handling Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
Attachment:
pgpgFnhtU3BGK.pgp
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |