| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
the time_t members in struct sched_param are just reserved space to
preserve size and alignment. when time_t changes to 64-bit on 32-bit
archs, this structure should not change.
make definition conditional on _REDIR_TIME64 to match the size of the
old time_t, which can be assumed to be long if _REDIR_TIME64 is
defined.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a _REDIR_TIME64 macro is introduced, which the arch's alltypes.h is
expected to define, to control redirection of symbol names for
interfaces that involve time_t and derived types. this ensures that
object files will only be linked to libc interfaces matching the ABI
whose headers they were compiled against.
along with time32 compat shims, which will be introduced separately,
the redirection also makes it possible for a single libc (static or
shared) to be used with object files produced with either the old
(32-bit time_t) headers or the new ones after 64-bit time_t switchover
takes place. mixing of such object files (or shared libraries) in the
same program will also be possible, but must be done with care; ABI
between libc and a consumer of the libc interfaces is guaranteed to
match by the the symbol name redirection, but pairwise ABI between
consumers of libc that define interfaces between each other in terms
of time_t is not guaranteed to match.
this change adds a dependency on an additional "GNU C" feature to the
public headers for existing 32-bit archs, which is generally
undesirable; however, the feature is one which glibc has depended on
for a long time, and thus which any viable alternative compiler is
going to need to provide. 64-bit archs are not affected, nor will
future 32-bit archs be, regardless of whether they are "new" on the
kernel side (e.g. riscv32) or just newly-added (e.g. a new sparc or
xtensa port). the same applies to newly-added ABIs for existing
machine-level archs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for time64 support on 32-bit archs, the kernel interfaces use a
timespec layout padded to match the representation of a pair of 64-bit
values, which requires endian-specific padding.
use of an ordinary, non-bitfield, named member for the padding is
undesirable because, on big endian archs, it would alter the
interpretation of traditional (non-designated) initializers of the
form {s,ns}, initializing the padding instead of the tv_nsec member.
unnamed bitfield members solve this problem by not taking part in
initialization, and were the expected solution when the kernel
interfaces were designed. however, they also have further advantages
which we take advantage of here:
positioning of the padding could be controlled by having a
preprocessor conditional with separate definitions of struct timespec
for little and big endian, but whether padding should appear at all is
a function of whether time_t is larger than long. this condition is
not something the preprocessor can determine unless we were to define
a new macro specifically for that purpose.
by using unnamed bitfield members instead of ordinary named members,
we can arrange for the size of the padding to collapse to zero when it
should not be present, just by using sizeof(time_t) and sizeof(long)
in the bitfield width expression, which can be any integer constant
expression.
|
|
|
|
|
|
|
|
|
|
|
| |
policy has long been that these definitions are purely a function of
whether long/pointer is 32- or 64-bit, and that they are not allowed
to vary per-arch. move the definition to the shared alltypes.h.in
fragment, using integer constant expressions in terms of sizeof to
vary the array dimensions appropriately. I'm not sure whether this is
more or less ugly than using preprocessor conditionals and two sets of
definitions here, but either way is a lot less ugly than repeating the
same thing for every arch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLONG_MAX is uniform for all archs we support and plenty of header and
code level logic assumes it is, so it does not make sense for limits.h
bits mechanism to pretend it's variable.
LONG_BIT can be defined in terms of LONG_MAX; there's no reason to put
it in bits.
by moving LONG_MAX definition to __LONG_MAX in alltypes.h and moving
LLONG_MAX out of bits, there are now no plain-C limits that are
defined in the bits header, so the bits header only needs to be
included in the POSIX or extended profiles. this allows the feature
test macro logic to be removed from the bits header, facilitating a
long-term goal of getting such logic out of bits.
having __LONG_MAX in alltypes.h will allow further generalization of
headers.
archs without a constant PAGESIZE no longer need bits/limits.h at all.
|
|
|
|
|
|
|
|
|
| |
the resolution of Austin Group issue #162 adds endian.h as a standard
header for future versions of the standard, making it no longer
acceptable for some of the functionality to be hidden behind
_BSD_SOURCE or _GNU_SOURCE. the definitions of the [lb]etoh{16,32,64}
function-like macros are kept conditional since they are alternate
names which the standard did not adopt.
|
|
|
|
|
|
|
|
| |
building on commit 97d35a552ec5b6ddf7923dd2f9a8eb973526acea,
__BYTE_ORDER is now available wherever alltypes.h is included.
endian.h should not be used since, in the future, it will expose
identifiers that are not in the reserved namespace for the headers
which were previously using it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this change is motivated by the intersection of several factors.
presently, despite being a nonstandard header, endian.h is exposing
the unprefixed byte order macros and functions only if _BSD_SOURCE or
_GNU_SOURCE is defined. this is to accommodate use of endian.h from
other headers, including bits headers, which need to define structure
layout in terms of endianness. with time64 switch-over, even more
headers will need to do this.
at the same time, the resolution of Austin Group issue 162 makes
endian.h a standard header for POSIX-future, requiring that it expose
the unprefixed macros and the functions even in standards-conforming
profiles. changes to meet this new requirement would break existing
internal usage of endian.h by causing it to violate namespace where
it's used.
instead, have the arch's alltypes.h define __BYTE_ORDER, either as a
fixed constant or depending on the right arch-specific predefined
macros for determining endianness. explicit literals 1234 and 4321 are
used instead of __LITTLE_ENDIAN and __BIG_ENDIAN so that there's no
danger of getting the wrong result if a macro is undefined and
implicitly evaluates to 0 at the preprocessor level.
the powerpc (32-bit) bits/endian.h being removed had logic for varying
endianness, but our powerpc arch has never supported that and has
always been big-endian-only. this logic is not carried over to the new
__BYTE_ORDER definition in alltypes.h.
|
|
|
|
|
|
|
| |
now that commit f7f1079796abc6f97c69521d2334e9c7d3945dd8 removed the
legacy i386 conditional definition, va_list is in no way
arch-specific, and has no reason to be in the future. move it to the
shared part of alltypes.h.in
|
|
|
|
|
|
|
| |
apply open_tree with OPEN_TREE_CLONE call to the entire subtree, see
linux commit a07b20004793d8926f78d63eb5980559f7813404
vfs: syscall: Add open_tree(2) to reference or clone a mount
|
|
|
|
|
|
|
|
|
|
| |
see
linux commit a528d35e8bfcc521d7cb70aaf03e1bd296c8493f
statx: Add a system call to make enhanced file info available
these are linux specific and not reserved names for fcntl.h so they
are under _BSD_SOURCE|_GNU_SOURCE.
|
|
|
|
|
|
|
| |
when set a pidfd is stored in parent_tidptr, see
linux commit b3e5838252665ee4cfa76b82bdf1198dca81e5be
clone: add CLONE_PIDFD
|
|
|
|
|
|
|
| |
ethertype for fake VLAN header for DSA, see
linux commit bf5bc3ce8a8f32a0d45b6820ede8f9fc3e9c23df
ether: Add dedicated Ethertype for pseudo-802.1Q DSA tagging
|
|
|
|
|
|
|
|
| |
commit 030e52639248ac8417a4934298caa78c21a228d1 added optreset, a BSD
extension to getopt duplicating the functionality (also an extension)
of setting optind to 0, but failed to provide a public declaration for
it. according to the BSD documentation and headers, the application is
not supposed to need to provide its own declaration.
|
|
|
|
|
|
|
| |
these are presently extensions, thus named with _np to match glibc and
other implementations that provide them; however they are likely to be
standardized in the future without the _np suffix as a result of
Austin Group issue 1208. if so, both names will be kept as aliases.
|
| |
|
|
|
|
|
|
|
|
| |
these members are associated with an unsupported option group. with
time_t changing size on 32-bit archs, all interfaces taking struct
sched_param arguments would need redirection and compat shims in order
to be able to continue offering these members, for no benefit. just
convert them to reserved space instead.
|
|
|
|
| |
This function is a GNU extension introduced in glibc 2.17.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
to make use of {sem,shm,msg}ctl IPC_STAT functionality to provide
64-bit time_t on 32-bit archs, IPC_STAT and related macros must be
defined with bit 8 (0x100) set. allow archs to define IPC_STAT in
bits/ipc.h, and define the other macros in terms of it so that they
all get the same value of the time64 bit.
|
|
|
|
|
|
|
| |
to request or change pointer auth keys for criu via ptrace, new in
linux commit d0a060be573bfbf8753a15dca35497db5e968bb0
arm64: add ptrace regsets for ptrauth key management
|
|
|
|
|
|
|
|
| |
RFC 4286: "The IPv4 multicast address for All-Snoopers is 224.0.0.106."
from
linux commit 4effd28c1245303dce7fd290c501ac2c11052114
bridge: join all-snoopers multicast address
|
|
|
|
|
|
|
|
|
| |
SO_BINDTOIFINDEX behaves similar to SO_BINDTODEVICE, but takes a
network interface index as argument, rather than the network
interface name. see
linux commit f5dd3d0c9638a9d9a02b5964c4ad636f06cf7e2c
net: introduce SO_BINDTOIFINDEX sockopt
|
|
|
|
|
|
|
|
| |
restricts router alert packets received by the socket to the
socket's namespace only. see
linux commit 9036b2fe092a107856edd1a3bad48b83f2b45000
net: ipv6: add socket option IPV6_ROUTER_ALERT_ISOLATE
|
|
|
|
|
|
|
|
| |
allows specifying that the speculative store bypass disable bit should
be cleared on exec. see
linux commit 71368af9027f18fe5d1c6f372cfdff7e4bde8b48
x86/speculation: Add PR_SPEC_DISABLE_NOEXEC
|
|
|
|
|
|
|
|
|
| |
needed for android so it can migrate from its ashmem to memfd.
allows making the memfd readonly for future users while keeping
a writable mmap of it. see
linux commit ab3948f58ff841e51feb845720624665ef5b7ef3
mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
includes changes from linux v5.1
linux commit 235328d1fa4251c6dcb32351219bb553a58838d2
fanotify: add support for create/attrib/move/delete events
linux commit 5e469c830fdb5a1ebaa69b375b87f583326fd296
fanotify: copy event fid info to user
linux commit e9e0c8903009477b630e37a8b6364b26a00720da
fanotify: encode file identifier for FAN_REPORT_FID
as well as earlier changes that were missed.
sys/statfs.h is included for fsid_t.
|
|
|
|
|
|
|
|
|
|
| |
this reverts commit f552c792c7ce5a560f214e1104d93ee5b0833967, which
exposed the sysmacros.h macros (device major/minor calculations) for
BSD and GNU profiles to mimic an unintentional glibc behavior some
code depended on. glibc has deprecated and since removed them as the
resolution to bug #19239, so it makes no sense for us to keep this
behavior. affected code should all have been fixed by now, and if it's
not yet fixed it needs to be for use with modern glibc anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FP_FAST_FMA can be defined if "the fma function generally executes about
as fast as, or faster than, a multiply and an add of double operands",
which can only be true if the fma call is inlined as an instruction.
gcc sets __FP_FAST_FMA if __builtin_fma is inlined as an instruction,
but that does not mean an fma call will be inlined (e.g. it is defined
with -fno-builtin-fma), other compilers (clang) don't even have such
macro, but this is the closest we can get.
(even if the libc fma implementation is a single instruction, the extern
call overhead is already too big when the macro is used to decide between
x*y+z and fma(x,y,z) so it cannot be based on libc only, defining the
macro unconditionally on targets which have fma in the base isa is also
incorrect: the compiler might not inline fma anyway.)
this solution works with gcc unless fma inlining is explicitly turned off.
|
|
|
|
|
|
|
|
|
|
| |
POSIX: "[If] either O_TTY_INIT is set in oflag or O_TTY_INIT has the
value zero, open() shall set any non-standard termios structure
terminal parameters to a state that provides conforming behavior."
The Linux kernel tty drivers always perform initialisation on their
devices to set known good termios values during the open(2) call. This
means that setting O_TTY_INIT to zero is conforming.
|
|
|
|
|
|
|
|
| |
This parameter was incorrectly declared to be a pointer to a function
accepting zero parameters. The intent of makecontext is that it is
possible to pass integer parameters to the function, so this should
have been a pointer to a function accepting an unspecified set of
parameters.
|
|
|
|
|
|
| |
aarch64 pointer authentication code related prctl that allows
reinitializing the key for the thread, added in linux commit
ba830885656414101b2f8ca88786524d4bb5e8c1
|
|
|
|
|
|
|
| |
NT_MIPS_MSA for ptrace access to mips simd arch reg set, added in linux
commit 3cd640832894b85b5929d5bda74505452c800421
NT_ARM_PAC_MASK for ptrace access to pointer auth code mask, added in
commit ec6e822d1a22d0eef1d1fa260dff751dba9a4258
|
|
|
|
|
|
|
| |
C-SKY support was added to binutils 2.32 in commit
b8891f8d622a31306062065813fc278d8a94fe21
the elf.h change was added to glibc 2.29 in commit
4975f0c3d0131fdf697be0b1631c265e5fd39088
|
|
|
|
|
| |
smoothed RTT for SCM_TIMESTAMPING_OPT_STATS control messages.
added in linux commit e8bd8fca6773ef49390269bd467bf940a0841ccf
|
|
|
|
|
| |
sockopt to enable gro for udp.
added in linux commit e20cf8d3f1f763ad28a9cb3b41305b8a8a42653e
|
|
|
|
|
|
| |
prctls to allow per task control of indirect branch speculation on x86.
added in linux commit 9137bb27e60e554dab694eafa4cca241fa3a694f
|
|
|
|
|
|
| |
ipv6 analogue of IP_MULTICAST_ALL sockopt.
added in linux commit 15033f0457dca569b284bef0c8d3ad55fb37eacb
|
|
|
|
| |
new in linux commit fa788d986a3aac5069378ed04697bd06f83d3488
|
|
|
|
|
| |
aarch64 supports 32MB and 512MB hugetlb page sizes too.
added in linux commit 20916d4636a9b3c1bf562b305f91d126771edaf9
|
|
|
|
|
|
|
|
| |
NT_MIPS_FP_MODE is new in linux commit
1ae22a0e35636efceab83728ba30b013df761592
NT_MIPS_DSP is new in linux commit
44109c60176ae73924a42a6bef64ef151aba9095
|
|
|
|
|
| |
used for optimizing the rxrpc protocol
added in linux commit 5271953cad31b97dea80f848c16e96ad66401199
|
|
|
|
|
|
|
|
|
|
|
|
| |
new fields for RFC 4898 tcp stats in linux
tcpi_bytes_sent added in commit ba113c3aa79a7f941ac162d05a3620bdc985c58d
tcpi_bytes_retrans added in commit fb31c9b9f6c85b1bad569ecedbde78d9e37cd87b
tcpi_dsack_dups added in commit 7e10b6554ff2ce7f86d5d3eec3af5db8db482caa
tcpi_reord_seen added in commit 7ec65372ca534217b53fd208500cf7aac223a383
The new fields change the size of a public struct and thus an ABI break,
but this is how the getsockopt TCP_INFO api is designed: the tcp_info
type must only be used with a length parameter in extern interfaces.
|
|
|
|
|
|
| |
inotify_add_watch flag to prevent modifying existing watch descriptors,
when used on an already watched inode it fails with EEXIST.
added in linux commit 4d97f7d53da7dc830dbf416a3d2a6778d267ae68
|
|
|
|
| |
added in linux commit 80b14dee2bea128928537d61c333f24cb8cbb62f
|
|
|
|
|
|
|
|
|
| |
On s390x, POSIX_FADV_DONTNEED and POSIX_FADV_NOREUSE have different
values than on all other architectures that Linux supports.
Handle this difference by wrapping their definitions in
include/fcntl.h in #ifdef, so that arch/s390x/bits/fcntl.h can
override them.
|
|
|
|
|
|
|
|
|
|
| |
as noted in Austin Group issue #1236, the XSI shading for TSVTX is
misplaced in the html version of the standard; it was only supposed to
be on the description text. the intent was that the definition always
be visible, which is reflected in the pdf version of the standard.
this reverts commits d93c0740d86aaf7043e79b942a6c0b3f576af4c8 and
729fef0a9358e2f6f1cd8c75a1a0f7ee48b08c95.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C11 removed the requirement that FILE be a complete type, which was
deemed erroneous, as part of the changes introduced by N1439 regarding
completeness of types (see footnote 6 for specific mention of FILE).
however the current version of POSIX is still based on C99 and
incorporates the old requirement that FILE be a complete type.
expose an arbitrary, useless complete type definition because the
actual object used to represent FILE streams cannot be public/ABI.
thanks to commit 13d1afa46f8098df290008c681816c9eb89ffbdb, we now have
a framework for suppressing the public complete-type definition of FILE
when stdio.h is included internally, so that a different internal
definition can be provided. this is perfectly well-defined, since the
same struct tag can refer to different types in different translation
units. it would be a problem if the implementation were accessing the
application's FILE objects or vice versa, but either would be
undefined behavior.
|