about summary refs log tree commit diff
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* use 64-bit msqid_ds layout in the generic version of bits/msg.hRich Felker2019-07-291-3/+0
| | | | | | this layout is more common already than the old generic, and should become even more common in the future with new archs added and with 64-bit time_t on 32-bit archs.
* duplicate generic bits/msg.h for each arch using it, in prep to changeRich Felker2019-07-295-0/+75
|
* remove duplicates of new generic bits/sem.hRich Felker2019-07-295-57/+0
| | | | | | some of these were not exact duplicates, but had gratuitously different naming for padding, or omitted the endian checks because the arch is fixed-endian.
* use 64-bit semid_ds layout in the generic version of bits/sem.hRich Felker2019-07-291-2/+0
| | | | | | | | this layout is slightly less common than the old generic one, but only because x86_64 and x32 wrongly (according to comments in the kernel headers) copied the i386 padding. for future archs, and with 64-bit time_t on 32-bit archs, the new layout here will become the most common, and it makes sense to treat it as the generic.
* collapse out byte order conditions in bits/sem.h for fixed-endian archsRich Felker2019-07-294-20/+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-297-0/+112
|
* extricate bits/sem.h from x32 time_t hackRich Felker2019-07-297-25/+36
| | | | | | | | | | | | | | various padding fields in the generic bits/sem.h were defined in terms of time_t as a cheap hack standing in for "kernel long", to allow x32 to use the generic version of the file. this was a really bad idea, as it ended up getting copied into lots of arch-specific versions of the bits file, and is a blocker to changing time_t to 64-bit on 32-bit archs. this commit adds an x32-specific version of the header, and changes padding type back from time_t to long (currently the same type on all archs but x32) in the generic header and all the others the hack got copied into.
* remove trailing newlines from various versions of bits/shm.hRich Felker2019-07-299-9/+0
|
* remove duplicates of new generic bits/shm.hRich Felker2019-07-295-123/+0
|
* use 64-bit shmid_ds layout in the generic version of bits/shm.hRich Felker2019-07-291-3/+0
| | | | | | | | | this layout is more common already than the old generic, and should become even more common in the future with new archs added and with 64-bit time_t on 32-bit archs. the duplicate arch-specific copies are not removed yet in this commit, so as to assist git tooling in copy/rename tracking.
* duplicate generic bits/shm.h for each arch using it, in prep to changeRich Felker2019-07-295-0/+140
| | | | | | | | | | | | | 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.
* remove x32 syscall timespec fixup hacksRich Felker2019-07-291-58/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | the x32 syscall interfaces treat timespec's tv_nsec member as 64-bit despite the API type being long and long being 32-bit in the ABI. this is no problem for syscalls that store timespecs to userspace as results, but caused uninitialized padding to be misinterpreted as the high bits in syscalls that take timespecs as input. since the beginning of the port, we've dealt with this situation with hacks in syscall_arch.h, and injected between __syscall_cp_c and __syscall_cp_asm, to special-case the syscall numbers that involve timespecs as inputs and copy them to a form suitable to pass to the kernel. commit 40aa18d55ab763e69ad16d0cf1cebea708ffde47 set the stage for removal of these hacks by letting us treat the "normal" x32 syscalls dealing with timespec as if they're x32's "time64" syscalls, effectively making x32 ax "time64-only 32-bit arch" like riscv32 will be when it's added. since then, all users of syscalls that x32's syscall_arch.h had hacks for have been updated to use time64 syscalls, so the hacks can be removed. there are still at least a few other timespec-related syscalls broken on x32, which were overlooked when the x32 hacks were done or added later. these include at least recvmmsg, adjtimex/clock_adjtime, and timerfd_settime, and they will be fixed independently later on.
* internally, define time64 syscalls on x32 as the existing syscallsRich Felker2019-07-271-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | x32 is odd in that it's the only ILP32 arch/ABI we have where time_t is 64-bit rather than (32-bit) long, and this has always been problematic in that it results in struct timespec having unused padding space, since tv_nsec has type long, which the kernel insists be zero- or sign-extended (due to negative tv_nsec being invalid, it doesn't matter which) to match the x86_64 type. up til now, we've had really ugly hacks in x32/syscall_arch.h to patch up the timespecs passed to the kernel. but the same requirement to zero- or sign-extend tv_nsec also applies to all the new time64 syscalls on true 32-bit archs. so let's take advantage of this to clean things up. this patch defines all of the time64 syscalls for x32 as aliases for the existing syscalls by the same name. this establishes the following invariants: - if the time64 form is defined, it takes time arguments as 64-bit objects, and tv_nsec inputs must be zero-/sign-extended to 64-bit. - if the time64 form is not defined, or if the time64 form is defined and is not equal to the "plain" form, the plain form takes time arguments as longs. this will avoid the need for protocols for archs to define appropriate types for each family of syscalls, and for the reader of the code to have to be aware of such type definitions. in some sense it might be simpler if the plain syscall form were undefined for x32, so that it would always take longs if defined. however, a number of these syscalls are used in contexts with a null time argument, or (e.g. futex) for commands that don't involve time at all, and having to introduce time64-specific logic to all those call points does not make sense. thus, while the "plain" forms are kept now just because they're needed until the affected code is converted over, they'll also almost surely be kept in the future as well.
* don't use futimesat syscall as utimensat fallback on x32Rich Felker2019-07-271-0/+2
| | | | | | | | | | kernel support for x32 was added long after the utimensat syscall was already available, so having a fallback is just wasted code size. also, for changes related to time64 support on 32-bit archs, I want to be able to assume the old futimesat syscall always works with longs, which is true except for x32. by ensuring that it's not used on x32, the needed invariant is established.
* remove mips/n32/64 stat struct hacks from syscall machineryRich Felker2019-07-186-213/+36
| | | | | | now that we have a kstat structure decoupled from the public struct stat, we can just use the broken kernel structures directly and let the code in fstatat do the translation.
* decouple struct stat from kernel typeRich Felker2019-07-1816-0/+337
| | | | | | | | | | | | | | | presently, all archs/ABIs have struct stat matching the kernel stat[64] type, except mips/mipsn32/mips64 which do conversion hacks in syscall_arch.h to work around bugs in the kernel type. this patch completely decouples them and adds a translation step to the success path of fstatat. at present, this is just a gratuitous copying, but it opens up multiple possibilities for future support for 64-bit time_t on 32-bit archs and for cleaned-up/unified ABIs. for clarity, the mips hacks are not yet removed in this commit, so the mips kstat structs still correspond to the output of the hacks in their syscall_arch.h files, not the raw kernel type. a subsequent commit will fix this.
* remove utterly wrong includes from mips64/n32 bits/stat.hRich Felker2019-07-182-6/+0
| | | | | | | | these were overlooked during review. bits headers are not allowed to pull in additional headers (note: that rule is currently broken in other places but just for endian.h). string.h has no place here anyway, and including bits/alltypes.h without defining macros to request types from it is a nop.
* use register constraint instead of memory operand for riscv64 atomicsRich Felker2019-07-171-8/+8
| | | | | | | | the "A" constraint is simply for an address expression that's a single register, but it's not yet supported by clang, and has no advantage here over just using a register operand for the address. the latter is actually preferable in the a_cas_p case because it avoids aliasing an lvalue onto the memory.
* fix riscv64 atomic asm constraintsRich Felker2019-07-171-6/+10
| | | | | | | most egregious problem was the lack of memory clobber and lack of volatile asm; this made the atomics memory barriers but not compiler barriers. use of "+r" rather than "=r" for a clobbered temp was also wrong, since the initial value is indeterminate.
* fix riscv64 syscall asm constraintRich Felker2019-07-171-1/+1
| | | | | | | having "+r"(a0) is redundant with "0"(a0) in syscalls with at least 1 arg, which is arguably a constraint violation (clang treats it as such), and an invalid input with indeterminate value in the 0-arg case. use the "=r"(a0) form instead.
* clean up mips64/n32 syscall asm constraintsRich Felker2019-07-162-54/+56
| | | | | | | | | | | | | | | | | ever since inline syscalls were added for (o32) mips in commit 328810d32524e4928fec50b57e37e1bf330b2e40, the asm has nonsensically loaded the syscall number, rather than taking $2 as an input constraint to let the compiler load it. commit cfc09b1ecf0c6981494fd73dffe234416f66af10 improved on this somewhat by allowing a constant syscall number to propagate into an immediate, but missed that the whole operation made no sense. now, only $4, $5, $6, $8, and $9 are potential input-only registers. $2 is always input and output, and $7 is both when it's an argument, otherwise output-only. previously, $7 was treated as an input (with a "1" constraint matching its output position) even when it was not an input, which was arguably undefined behavior (asm input from indeterminate value). this is corrected.
* deduplicate mips64/n32 syscall clobbered register listsRich Felker2019-07-162-28/+22
| | | | | | | | | | | | | | this patch is not purely non-functional changes, since before, $8 and $9 were wrongly in the clobberlist for syscalls with fewer than 5 or 6 arguments. of course it's impossible for syscalls to have different clobbers depending on their number of arguments. the clobberlist for the recently-added 5- and 6-argument forms was correct, and for the 0- to 4-argument forms was erroneously copied from the mips o32 ABI where the additional arguments had to be passed on the stack. in making this change, I reviewed the kernel sources, and $8 and $9 are always saved for 64-bit kernels since they're part of the syscall argument list for n32 and n64 ABIs.
* fix build failure on arm building C code in thumb1 modeRich Felker2019-07-151-1/+1
| | | | | | | | | | | | a fully thumb1 build is not supported because some asm files are incompatible with thumb1, but apparently it works to compile the C code as thumb1 commit 06fbefd10046a0fae7e588b7c6d25fb51811b931 caused this regression but introducing use of the clz instruction, which is not supported in arm mode prior to v5, and not supported in thumb prior to thumb2 (v6t2). commit 1b9406b03c0a94ebe2076a8fc1746a8c45e78a83 fixed the issue only for arm mode pre-v5 but left thumb1 broken.
* fix conflicting mips and powerpc definitions for TIOCSER_TEMT macroSamuel Holland2019-07-105-5/+5
| | | | | | | | Commit 3517d74a5e04a377192d1f4882ad6c8dc22ce69a changed the token in sys/ioctl.h from 0x01 to 1, so bits/termios.h no longer matches. Revert the bits/termios.h change to keep the headers in sync. This reverts commit 9eda4dc69c33852c97c6f69176bf45ffc80b522f.
* remove spurious MAP_32BIT definition from riscv64 archRich Felker2019-07-041-1/+0
| | | | | | this was apparently copied from x86_64; it's not part of the kernel API for riscv64. this change eliminates the need for a riscv64-specific bits header and lets it use the generic one.
* add new syscall numbers from linux v5.1Szabolcs Nagy2019-07-0115-0/+327
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* mips64: fix syscall numbers of io_pgetevents and rseqSzabolcs Nagy2019-07-011-2/+2
| | | | | | | | | the numbers added in commit d149e69c02eb558114f20ea718810e95538a3b2f add io_pgetevents and rseq syscall numbers from linux v4.18 were incorrect.
* s390x: drop SO_ definitions from bits/socket.hSzabolcs Nagy2019-07-011-28/+0
| | | | the s390x definitions matched the generic ones in sys/socket.h.
* add riscv64 architecture supportRich Felker2019-06-1425-0/+835
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: Alex Suykov <alex.suykov@gmail.com> Author: Aric Belsito <lluixhi@gmail.com> Author: Drew DeVault <sir@cmpwn.com> Author: Michael Clark <mjc@sifive.com> Author: Michael Forney <mforney@mforney.org> Author: Stefan O'Rear <sorear2@gmail.com> This port has involved the work of many people over several years. I have tried to ensure that everyone with substantial contributions has been credited above; if any omissions are found they will be noted later in an update to the authors/contributors list in the COPYRIGHT file. The version committed here comes from the riscv/riscv-musl repo's commit 3fe7e2c75df78eef42dcdc352a55757729f451e2, with minor changes by me for issues found during final review: - a_ll/a_sc atomics are removed (according to the ISA spec, lr/sc are not safe to use in separate inline asm fragments) - a_cas[_p] is fixed to be a memory barrier - the call from the _start assembly into the C part of crt1/ldso is changed to allow for the possibility that the linker does not place them nearby each other. - DTP_OFFSET is defined correctly so that local-dynamic TLS works - reloc.h LDSO_ARCH logic is simplified and made explicit. - unused, non-functional crti/n asm files are removed. - an empty .sdata section is added to crt1 so that the __global_pointer reference is resolvable. - indentation style errors in some asm files are fixed.
* make powerpc64 vrregset_t logical layout match expected APIRich Felker2019-05-221-1/+4
| | | | | | | | | between v2 and v3 of the powerpc64 port patch, the change was made from a 32x4 array of 32-bit unsigned ints for vrregs[] to a 32-element array of __int128. this mismatches the API applications working with mcontext_t expect from glibc, and seems to have been motivated by a misinterpretation of a comment on how aarch64 did things as a suggestion to do the same on powerpc64.
* fix vrregset_t layout and member naming on powerpc64Rich Felker2019-05-221-4/+8
| | | | | | | | | | | | | | | | | | the mistaken layout seems to have been adapted from 32-bit powerpc, where vscr and vrsave are packed into the same 128-bit slot in a way that looks like it relies on non-overlapping-ness of the value bits in big endian. the powerpc64 port accounted for the fact that the 64-bit ABI puts each in its own 128-bit slot, but ordered them incorrectly (matching the bit order used on the 32-bit ABI), and failed to account for vscr being padded according to endianness so that it can be accessed via vector moves. in addition to ABI layout, our definition used different logical member layout/naming from glibc, where vscr is a structure to facilitate access as a 32-bit word or a 128-bit vector. the inconsistency here was unintentional, so fix it.
* improve i386 inline syscall asm on non-broken compilersRich Felker2019-05-111-1/+20
| | | | | | | | | | | | | | | | | we have to avoid using ebx unconditionally in asm constraints for i386, because gcc 3 and 4 and possibly other simplistic compilers (pcc?) implement PIC via making ebx a fixed-use register, and disallow its use for anything else. rather than hard-coding knowledge of which compilers work (at least gcc 5+ and clang), perform a configure test; this should give us the good codegen on any new compilers we don't yet know about. swapping ebx and edx is kept for 1- and 2-arg syscalls because it avoids having any spills/stack-frame at all in small functions. for 6-arg, if ebx is directly usable, the complex shuffling introduced in commit c8798ef974d21c338a7d8d874a402978ffc6168e can be avoided, and ebp can be loaded the same way ebx is in 5-arg syscalls for compilers that don't support direct use of ebx.
* fix regression in i386 inline syscall asm producing invalid codeRich Felker2019-05-101-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 22e5bbd0deadcbd767864bd714e890b70e1fe1df inlined the i386 syscall mechanism, but wrongly assumed memory operands to the 5- and 6-argument syscall asm would be esp-based. however, nothing in the constraints prevented them from being ebx- or ebp-based, and in those cases, ebx and ebp could be clobbered before use of the memory operand was complete. in the 6-argument case, this prevented restoration of the original register values before the end of the asm block, breaking the asm contract since ebx and ebp are not marked as clobbered. (they can't be, because lots of compilers don't accept these registers in constraints or clobbers if PIC or frame pointer is enabled). doing this right is complicated by the fact that, after a single push, no operands which might be memory operands are usable. if they are esp-based, the value of esp has changed, rendering them invalid. introduce some new dances to load the registers. for the 5-arg case, push the operand that may be a memory operand first, and after that, it doesn't matter if the operand is invalid, since we'll just use the newly pushed value. for the 6-arg case, we need to put both operands in memory to begin with, like the old non-inline code prior to commit 22e5bbd0deadcbd767864bd714e890b70e1fe1df accepted, so that there's only one potentially memory-based operand to the asm. this can then be saved with a single push, and after that the values can be read off into the registers they're needed in. there's some size overhead, but still a lot less execution overhead than the old out-of-line code. doing it better depends on a modern compiler that lets you use ebx and ebp in asm constraints without restriction. the failure modes on compilers where this doesn't work are inconsistent and dangerous (on at least some gcc versions 4.x and earlier, wrong codegen!), so this is a delicate matter. it can be addressed later if needed.
* fix broken posix_fadvise on mips due to missing 7-arg syscall supportRich Felker2019-05-051-0/+25
| | | | | | | | commit 788d5e24ca19c6291cebd8d1ad5b5ed6abf42665 exposed the breakage at build time by removing support for 7-argument syscalls; however, the external __syscall function provided for mips before did not pass a 7th argument from the stack, so the behavior was just silently broken.
* fix build regression on mips n32 due to typo in new inline syscallRich Felker2019-05-051-1/+1
| | | | | commit 1bcdaeee6e659f1d856717c9aa562a068f2f3bd4 introduced the regression.
* fix passing of 64-bit syscall arguments on microblazeRich Felker2019-05-051-1/+1
| | | | | | | | | | | | | | | this has been wrong since the beginning of the microblaze port: the syscall ABI for microblaze does not align 64-bit arguments on even register boundaries. commit 788d5e24ca19c6291cebd8d1ad5b5ed6abf42665 exposed the problem by introducing references to a nonexistent __syscall7. the ABI is not documented well anywhere, but I was able to confirm against both strace source and glibc source that microblaze is not using the alignment. per the syscall(2) man page, posix_fadvise, ftruncate, pread, pwrite, readahead, sync_file_range, and truncate were all affected and either did not work at all, or only worked by chance, e.g. when the affected argument slots were all zero.
* fix regression in s390x SO_PEERSEC definitionRich Felker2019-04-231-0/+1
| | | | | | | analogous to commit efda534b212f713fe2b92a62b06e45f656b763ce for powerpc. commit 587f5a53bc3a68d80b239ba515d583df690a96df moved the definition of SO_PEERSEC to bits/socket.h for archs where the SO_* macros differ.
* math: add fp_arch.h with fp_barrier and fp_force_evalSzabolcs Nagy2019-04-172-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C99 has ways to support fenv access, but compilers don't implement it and assume nearest rounding mode and no fp status flag access. (gcc has -frounding-math and then it does not assume nearest rounding mode, but it still assumes the compiled code itself does not change the mode. Even if the C99 mechanism was implemented it is not ideal: it requires all code in the library to be compiled with FENV_ACCESS "on" to make it usable in non-nearest rounding mode, but that limits optimizations more than necessary.) The math functions should give reasonable results in all rounding modes (but the quality may be degraded in non-nearest rounding modes) and the fp status flag settings should follow the spec, so fenv side-effects are important and code transformations that break them should be prevented. Unfortunately compilers don't give any help with this, the best we can do is to add fp barriers to the code using volatile local variables (they create a stack frame and undesirable memory accesses to it) or inline asm (gcc specific, requires target specific fp reg constraints, often creates unnecessary reg moves and multiple barriers are needed to express that an operation has side-effects) or extern call (only useful in tail-call position to avoid stack-frame creation and does not work with lto). We assume that in a math function if an operation depends on the input and the output depends on it, then the operation will be evaluated at runtime when the function is called, producing all the expected fenv side-effects (this is not true in case of lto and in case the operation is evaluated with excess precision that is not rounded away). So fp barriers are needed (1) to prevent the move of an operation within a function (in case it may be moved from an unevaluated code path into an evaluated one or if it may be moved across a fenv access), (2) force the evaluation of an operation for its side-effect when it has no input dependency (may be constant folded) or (3) when its output is unused. I belive that fp_barrier and fp_force_eval can take care of these and they should not be needed in hot code paths.
* implement inline 5- and 6-argument syscalls for mipsn32 and mips64Rich Felker2019-04-102-29/+68
| | | | | | | | | | n32 and n64 ABIs add new argument registers vs o32, so that passing on the stack is not necessary, so it's not clear why the 5- and 6-argument versions were special-cased to begin with; it seems to have been pattern-copying from arch/mips (o32). i've treated the new argument registers like the first 4 in terms of clobber status (non-clobbered). hopefully this is correct.
* cleanup mips64 syscall_arch functionsRich Felker2019-04-101-18/+9
|
* implement inline 5- and 6-argument syscalls for mipsRich Felker2019-04-101-6/+33
| | | | | | | | the OABI passes these on the stack, using the convention that their position on the stack is as if the first four arguments (in registers) also had stack slots. originally this was deemed too awkward to do inline, falling back to external __syscall, but it's not that bad and now that external __syscall is being removed, it's necessary.
* use inline syscalls for powerpc (32-bit)Rich Felker2019-04-101-2/+84
| | | | | | the inline syscall code is copied directly from powerpc64. the extent of register clobber specifiers may be excessive on both; if that turns out to be the case it can be fixed later.
* remove cruft for supposedly-buggy clang from or1k & microblaze syscall_archRich Felker2019-04-102-18/+0
| | | | | | | | | it was never demonstrated to me that this workaround was needed, and seems likely that, if there ever was any clang version for which it was needed, it's old enough to be unusably buggy in other ways. if it turns out some compilers actually can't do the register allocation right, we'll need to replace this with inline shuffling code, since the external __syscall dependency is being removed.
* overhaul i386 syscall mechanism not to depend on external asm sourceRich Felker2019-04-101-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is the first part of a series of patches intended to make __syscall fully self-contained in the object file produced using syscall.h, which will make it possible for crt1 code to perform syscalls. the (confusingly named) i386 __vsyscall mechanism, which this commit removes, was introduced before the presence of a valid thread pointer was mandatory; back then the thread pointer was setup lazily only if threads were used. the intent was to be able to perform syscalls using the kernel's fast entry point in the VDSO, which can use the sysenter (Intel) or syscall (AMD) instruction instead of int $128, but without inlining an access to the __syscall global at the point of each syscall, which would incur a significant size cost from PIC setup everywhere. the mechanism also shuffled registers/calling convention around to avoid spills of call-saved registers, and to avoid allocating ebx or ebp via asm constraints, since there are plenty of broken-but-supported compiler versions which are incapable of allocating ebx with -fPIC or ebp with -fno-omit-frame-pointer. the new mechanism preserves the properties of avoiding spills and avoiding allocation of ebx/ebp in constraints, but does it inline, using some fairly simple register shuffling, and uses a field of the thread structure rather than global data for the vdso-provided syscall code address. for now, the external __syscall function is refactored not to use the old __vsyscall so it can be kept, but the intent is to remove it too.
* aarch64: add HWCAP_ definitions from linux v5.0Szabolcs Nagy2019-03-131-0/+3
| | | | | | | | HWCAP_SB - speculation barrier instruction available added in linux commit bd4fb6d270bc423a9a4098108784f7f9254c4e6d HWCAP_PACA, HWCAP_PACG - pointer authentication instructions available (address and generic) added in linux commit 7503197562567b57ec14feb3a9d5400ebc56812f
* aarch64, or1k: add kexec_file_load syscall number from linux v5.0Szabolcs Nagy2019-03-132-0/+2
| | | | added in linux commit 4e21565b7fd4d9045765f697887e74a704135fe2
* powerpc: add PTRACE_SYSEMU from linux v4.20Szabolcs Nagy2019-03-132-0/+4
| | | | added in linux commit 5521eb4bca2db733952f068c37bdf3cd656ad23c
* aarch64: add HWCAP_SSBS from linux v4.20Szabolcs Nagy2019-03-131-0/+1
| | | | | for armv8.5 speculative store bypass PSTATE bit support, added in linux commit d71be2b6c0e19180b5f80a6d42039cc074a693a2
* bits/ioctl.h: add TIOC{G,S}ISO7816 from linux v4.20Szabolcs Nagy2019-03-131-0/+2
| | | | | | | | | | | | | | | | | | | | | ISO7816 smart cards ioctls. linux commit ad8c0eaa0a418ae8ef3f9217638bb86439399eac the actual kernel definitions are #define TIOCGISO7816 _IOR('T', 0x42, struct serial_iso7816) #define TIOCSISO7816 _IOWR('T', 0x43, struct serial_iso7816) where struct serial_iso7816 is defined in linux/serial.h as struct serial_iso7816 { __u32 flags; __u32 tg; __u32 sc_fi; __u32 sc_di; __u32 clk; __u32 reserved[5]; };
* arm: add io_pgetevents syscall number from v4.19Szabolcs Nagy2019-03-131-0/+1
| | | | wired up in linux commit 73aeb2cbcdc9be391b3d32a55319a59ce425426f
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-09 10:06:50 +0000