about summary refs log tree commit diff
path: root/arch/m68k/bits
Commit message (Collapse)AuthorAgeFilesLines
* add new syscall numbers from linux v5.2Szabolcs Nagy2019-09-111-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | new mount api syscalls were added, same numers on all targets, see linux commit a07b20004793d8926f78d63eb5980559f7813404 vfs: syscall: Add open_tree(2) to reference or clone a mount linux commit 2db154b3ea8e14b04fee23e3fdfd5e9d17fbc6ae vfs: syscall: Add move_mount(2) to move mounts around linux commit 24dcb3d90a1f67fe08c68a004af37df059d74005 vfs: syscall: Add fsopen() to prepare for superblock creation linux commit ecdab150fddb42fe6a739335257949220033b782 vfs: syscall: Add fsconfig() for configuring and managing a context linux commit 93766fbd2696c2c4453dd8e1070977e9cd4e6b6d vfs: syscall: Add fsmount() to create a mount for a superblock linux commit cf3cba4a429be43e5527a3f78859b1bfd9ebc5fb vfs: syscall: Add fspick() to select a superblock for reconfiguration linux commit 9c8ad7a2ff0bfe58f019ec0abc1fb965114dde7d uapi, x86: Fix the syscall numbering of the mount API syscalls [ver #2] linux commit d8076bdb56af5e5918376cd1573a6b0007fc1a89 uapi: Wire up the mount API syscalls on non-x86 arches [ver #2]
* honor __WCHAR_TYPE__ on archs with legacy long definition of wchar_tRich Felker2019-09-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | historically, a number of 32-bit archs used long rather than int for wchar_t, for no good reason. GCC still uses the historical types, but clang replaced them all with int, and it seems PCC uses int too. mismatching the compiler's type for wchar_t is not an option due to wide string literals. note that the mismatch does not affect C++ ABI since wchar_t is its own builtin type/keyword in C++, distinct from both int and long, not a typedef. i386 already worked around this by honoring __WCHAR_TYPE__ if defined by the compiler, and only using the official legacy ABI type if not. add the same to the other affected archs. it might make sense at some point to switch to using int as the default if __WCHAR_TYPE__ is not defined, if the expectations is that new compilers will treat int as the correct choice, but it's unlikely that the case where __WCHAR_TYPE__ is undefined will ever be used anyway. I actually wanted to move the definition of wchar_t to the top-level shared alltypes.h.in, using __WCHAR_TYPE__ and falling back to int if not defined, but that can't be done without assuming all compilers define __WCHAR_TYPE__ thanks to some pathological archs where the ABI has wchar_t as an unsigned type.
* move IPC_STAT definition to a new bits/ipcstat.h fileRich Felker2019-08-021-0/+1
| | | | | | | | | | | | | | | otherwise, 32-bit archs that could otherwise share the generic bits/ipc.h would need to duplicate the struct ipc_perm definition, obscuring the fact that it's the same. sysvipc is not widely used and these headers are not commonly included, so there is no performance gain to be had by limiting the number of indirectly included files here. files with the existing time32 definition of IPC_STAT are added to all current 32-bit archs now, so that when it's changed the change will show up as a change rather than addition of a new file where it's less obvious that the value is changing vs the generic one that was used before.
* duplicate generic bits/msg.h for each arch using it, in prep to changeRich Felker2019-07-291-0/+15
|
* collapse out byte order conditions in bits/sem.h for fixed-endian archsRich Felker2019-07-291-5/+0
| | | | | having preprocessor conditionals on byte order in the bits headers for fixed-endian archs is confusing at best. remove them.
* duplicate generic bits/sem.h for each arch using it, in prep to changeRich Felker2019-07-291-0/+16
|
* remove trailing newlines from various versions of bits/shm.hRich Felker2019-07-291-1/+0
|
* duplicate generic bits/shm.h for each arch using it, in prep to changeRich Felker2019-07-291-0/+28
| | | | | | | | | | | | | there are more archs sharing the generic 64-bit version of the struct, which is uniform and much more reasonable, than sharing the current "generic" one, and depending on how time64 sysvipc is done for 32-bit archs, even more may be sharing the "64-bit version" in the future. so, duplicate the current generic to all archs using it (arm, i386, m68k, microblaze, or1k) so that the generic can be changed freely. this is recorded as its own commit mainly as a hint to git tooling, to assist in copy/move tracking.
* add new syscall numbers from linux v5.1Szabolcs Nagy2019-07-011-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | syscall numbers are now synced up across targets (starting from 403 the numbers are the same on all targets other than an arch specific offset) IPC syscalls sem*, shm*, msg* got added where they were missing (except for semop: only semtimedop got added), the new semctl, shmctl, msgctl imply IPC_64, see linux commit 0d6040d4681735dfc47565de288525de405a5c99 arch: add split IPC system calls where needed new 64bit time_t syscall variants got added on 32bit targets, see linux commit 48166e6ea47d23984f0b481ca199250e1ce0730a y2038: add 64-bit time_t syscalls to all 32-bit architectures new async io syscalls got added, see linux commit 2b188cc1bb857a9d4701ae59aa7768b5124e262e Add io_uring IO interface linux commit edafccee56ff31678a091ddb7219aba9b28bc3cb io_uring: add support for pre-mapped user IO buffers a new syscall got added that uses the fd of /proc/<pid> as a stable handle for processes: allows sending signals without pid reuse issues, intended to eventually replace rt_sigqueueinfo, kill, tgkill and rt_tgsigqueueinfo, see linux commit 3eb39f47934f9d5a3027fe00d906a45fe3a15fad signal: add pidfd_send_signal() syscall on some targets (arm, m68k, s390x, sh) some previously missing syscall numbers got added as well.
* add support for arch-specific ptrace command macrosSzabolcs Nagy2018-07-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | sys/ptrace.h is target specific, use bits/ptrace.h to add target specific macro definitions. these macros are kept in the generic sys/ptrace.h even though some targets don't support them: PTRACE_GETREGS PTRACE_SETREGS PTRACE_GETFPREGS PTRACE_SETFPREGS PTRACE_GETFPXREGS PTRACE_SETFPXREGS so no macro definition got removed in this patch on any target. only s390x has a numerically conflicting macro definition (PTRACE_SINGLEBLOCK). the PT_ aliases follow glibc headers, otherwise the definitions come from linux uapi headers except ones that are skipped in glibc and there is no real kernel support (s390x PTRACE_*_AREA) or need special type definitions (mips PTRACE_*_WATCH_*) or only relevant for linux 2.4 compatibility (PTRACE_OLDSETOPTIONS).
* add m68k reg.h and user.hRich Felker2018-06-262-0/+78
|
* fix m68k float.h long double exponent rangeRich Felker2018-06-201-2/+2
| | | | | unlike the x86 variant, the m68k ld80 format allows (biased) exponent zero with mantissa msb set, thereby extending the normal range.
* add m68k portRich Felker2018-06-1912-0/+692
three ABIs are supported: the default with 68881 80-bit fpu format and results returned in floating point registers, softfloat-only with the same format, and coldfire fpu with IEEE single/double only. only the first is tested at all, and only under qemu which has fpu emulation bugs. basic functionality smoke tests have been performed for the most common arch-specific breakage via libc-test and qemu user-level emulation. some sysvipc failures remain, but are shared with other big endian archs and will be fixed separately.