placing the opening brace on the same line as the struct keyword/tag
is the style I prefer and seems to be the prevailing practice in more
recent additions.

these changes were generated by the command:

find include/ arch/*/bits -name '*.h' \
-exec sed -i '/^struct [^;{]*$/{N;s/\n/ /;}' {} +

and subsequently checked by hand to ensure that the regex did not pick
up any false positives.

with this change, all three files are identical.

it seems it was a typo.

these were incorrectly using the generic definitions.

same changes to the defined macros as in powerpc and generic bits.

same changes as in the generic header.

and BOTHER and IBSHIFT were removed (present in linux uapi but not
in glibc) and TIOCSER_TEMT was added (present in glibc).

add EXTA, EXTB, CIBAUD, CMSPAR, XCASE macros and hide them as well as
CBAUD, ECHOCTL, ECHOPRT, ECHOKE, FLUSHO, PENDIN in standard mode.

the new macros are both in glibc termios.h and in linux asm/termbits.h,
the later also contains IBSHIFT and BOTHER, those were not added.

these are not standard macros, but some of them are in the reserved
namespace so could be exposed, the ones which are not reserved are
CIBAUD, CMSPAR and XCASE (which was removed in issue 6), the rest
got hidden to be consistent with glibc.

arm ioctl.h is the same as the generic one except this macro,
so a workaround solution is used to avoid another ioctl.h copy.

musl does not define these on other targets either.

it seems it was a typo.

TIOCM_ macros were wrongly using the asm-generic/termios.h definitions
instead of the mips specific ones from asm/termios.h

mips and powerpc use their own asm/ioctls.h, not the asm-generic/ioctls.h
and they lack termiox macros that are available on other targets.
see kernel commit 1d65b4a088de407e99714fdc27862449db04fb5c

these are defined in linux asm/ioctls.h.
(powerpc64 and powerpc bits/ioctl.h are now identical)

glibc ioctl.h has it too.

TIOCTTYGSTRUCT, TIOCGHAYESESP, TIOCSHAYESESP and TIOCM_MODEM_BITS
were removed from the linux uapi and not present in glibc ioctl.h

they were slightly different in musl, but should be the same:
the linux uapi and glibc headers are not different.

the (unused) speed fields were omitted when these ports were first
added (within this release cycle, so not present in any release yet)
in accordance with how glibc defines the structure on mips archs.
however their omission does not match existing musl practice/intent.

glibc provides its own, mostly-unified termios structure definition
and performs translation in userspace to match the kernel structure
for the arch, but has gratuitous differences on a few archs like mips,
presumably as a result of historical mistakes. some other libcs use
the kernel definitions directly. musl essentially does that, by
matching the kernel layout in the part of the structure the kernel
will read/write, but leaves additional space at the end for
extensibility. these are nominally the (nonstandard) speed fields and
(on most archs) extra c_cc elements, but since they are not used they
could be repurposed if there's ever a need.

commit 6d38c9cf provided an
arm-specific version of posix_fadvise to address the alternate
argument order the kernel expects on arm, but neglected to address
that powerpc (32-bit) has the same issue. instead of having arch
variant files in duplicate, simply put the alternate version in the
top-level file under the control of a macro defined in syscall_arch.h.

the arm version of the syscall has a custom argument ordering to avoid
needing a 7-argument syscall due to 64-bit argument alignment.

when commit 0b6eb2df added the
parentheses around __syscall to invoke the function directly, there
was no __syscall7 in the syscall macro infrastructure, so this hack
was needed. commit 9a3bbce4 fixed that
but failed to remove the hack.

loop over an address family / resource record mapping to avoid
repetitive code.

don't send a query that may be malformed.

the kernel ABI value for RUSAGE_CHILDREN is -1, not 1. the latter is
actually interpreted as RUSAGE_THREAD, to obtain values for just the
calling thread and not the whole process.

mistakenly ordering strings before addresses in the result buffer
broke the alignment that the preceding code had set up.

Linux's documentation (robust-futex-ABI.txt) claims that, when a
process dies with a futex on the robust list, bit 30 (0x40000000) is
set to indicate the status. however, what actually happens is that
bits 0-30 are replaced with the value 0x40000000, i.e. bits 0-29
(containing the old owner tid) are cleared at the same time bit 30 is
set.

our userspace-side code for robust mutexes was written based on that
documentation, assuming that kernel would never produce a futex value
of 0x40000000, since the low (owner) bits would always be non-zero.
commit d338b506 introduced this
assumption explicitly while fixing another bug in how non-recoverable
status for robust mutexes was tracked. presumably the tests conducted
at that time only checked non-process-shared robust mutexes, which are
handled in pthread_exit (which implemented the documented kernel
protocol, not the actual one) rather than by the kernel.

change pthread_exit robust list processing to match the kernel
behavior, clearing bits 0-29 while setting bit 30, and use the value
0x7fffffff instead of 0x40000000 to encode non-recoverable status. the
choice of value here is arbitrary; any value with at least one of bits
0-29 set should work just as well,

despite clarifications made to the COPYRIGHT file in commit
f0a61399, there continues to be
confusion about whether the permissions granted actually apply to all
files. I am the sole author of these files and clearly intend, and
have always intended, for the grant of permission to apply to them.

compilers are free not to copy, or in some cases to clobber, padding
bytes in a structure. while it's an aliasing violation, and thus
undefined behavior, to copy or manipulate other sockaddr types using
sockaddr_storage, it seems likely that traditional code attempts to do
so, and the original intent of the sockaddr_storage structure was
probably to allow such usage.

in the interest of avoiding silent and potentially dangerous breakage,
ensure that there are no actual padding bytes in sockaddr_storage by
moving and adjusting the size of the __ss_padding member so that it
fits exactly.

this change also removes a silent assumption that the alignment of
long is equal to its size.

kernel connection multiplexor macros AF_KCM, PF_KCM, SOL_KCM were
added in linux commit ab7ac4eb9832e32a09f4e8042705484d2fb0aad3

MSG_BATCH sendmsg flag for performance optimization was added
in linux commit f092276d85b82504e8a07498f4e9e0c51f06745c

SOL_* macros are now synced with linux socket.h which is not a uapi
header and glibc did not have the macros either, but that has changed
http://sourceware.org/ml/libc-alpha/2016-05/msg00322.html

new fields and associated linux commit:
tcpi_notsent_bytes, tcpi_min_rtt cd9b266095f422267bddbec88f9098b48ea548fc
tcpi_data_segs_in, tcpi_data_segs_out a44d6eacdaf56f74fad699af7f4925a5f5ac0e7f

flag for new cgroup namespace, added in linux commit
5e2bec7c2248ae27c5b16cd97215ae05c1d39179

x86 protection key faults are reported in the si_pkey field,
added in linux commit cd0ea35ff5511cde299a61c21a95889b4a71464e

ethertype for macsec added in linux commit
dece8d2b78d19df7fe5e4e965f1f0d1a3e188d1b

new socket option so application can give advice about routing
path quality of connected udp sockets, added in linux commit
a87cb3e48ee86d29868d3f59cfb9ce1a8fa63314

the syscalls take an additional flag argument, they were added in commit
f17d8b35452cab31a70d224964cd583fb2845449 and a RWF_HIPRI priority hint
flag was added to linux/fs.h in 97be7ebe53915af504fb491fb99f064c7cf3cb09.

the syscall is not allocated for microblaze and sh yet.

the difference of pointers is a signed type ptrdiff_t; if it is only
32-bit, left-shifting it by 30 bits produces undefined behavior. cast
the difference to an appropriate unsigned type, uint32_t, before
shifting to avoid this.

the a64l function is specified to return a signed 32-bit result in
type long. as noted in the bug report by Ed Schouten, converting
implicitly from uint32_t only produces the desired result when long is
a 32-bit type. since the computation has to be done in unsigned
arithmetic to avoid overflow, simply cast the result to int32_t.

further, POSIX leaves the behavior on invalid input unspecified but
not undefined, so we should not take the difference between the
potentially-null result of strchr and the base pointer without first
checking the result. the simplest behavior is just returning the
partial conversion already performed in this case, so do that.

previously, the only way the stopping condition could be met with
correct lengths in the headers invoked undefined behavior, adding
sizeof(struct cmsghdr) beyond the end of the cmsg buffer.

instead, compute and compare sizes rather than pointers.