Signed-off-by: Kenta Tada <Kenta.Tada@sony.com>

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

On sparc-unknown-linux-gnu, char is signed, not unsigned.

Support was previously added to gnu x86_64 and all musl targets but
others were not included because of a roundtrip issue [1].

This commit adds support for the ip_mreqn struct on all Linux GNU
targets which did not have the roundtrip issue.

[1]: https://github.com/rust-lang/libc/issues/1558



Signed-off-by: Bartel Sielski <bartel.sielski@gmail.com>

Move the link line for `libdl` up to `src/unix/mod.rs`, making it easier
to see all the libraries `libc` links to.

This also makes `libdl` respect `target-feature=+crt-static`.

The two library blocks that specify `#[link(name = "util")]` do not
actually reference any functions in `libutil`; the functions that do use
`libutil` don't have any reference to it. And having two library blocks
specify it results in two separate inclusions of `-lutil` on the linker
command line. Move the link lines up to `src/unix/mod.rs`, making it
easier to see all the libraries `libc` links to.

This also makes `libutil` respect `target-feature=+crt-static`.

These syscalls were added recently, and therefore have consistent
numbers across different architetures (other than the weird offsetting
on some platforms).

The SIGCHLD variant of the siginfo structure also provides fields for
user and system time; expose those as well.

The first 3 fields of `siginfo_t` have different orders on MIPS. When
casting `siginfo_t` to a different type to access the fields of the
`sifields` union, avoid giving names to the first three fields, since
they're only present for memory layout and shouldn't be accessed from
the casted structure type.

On Linux, siginfo_t cannot expose these fields directly due to
https://github.com/rust-lang/libc/issues/716 , so expose them as
functions, just like si_addr and si_value.

In order to get alignment correct on both 32-bit and 64-bit
architectures, define an sifields union that includes a pointer field,
to ensure that it has the same alignment as a pointer.

Reorganized some constants as well so they're grouped a bit better.

Headers I used:

Oh, for reference, here are the headers I used while working on this:

- musl: https://git.musl-libc.org/cgit/musl/tree/include/regex.h?id=8327ae0cb23b799bc55a45e0d4bd95f5a2b1cdf1
- glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/regex.h;h=87cce7f5cb8cc3b678467329b479bd511e250e61;hb=HEAD
- macOS: https://opensource.apple.com/source/Libc/Libc-997.90.3/include/regex.h.auto.html
- FreeBSD: https://github.com/freebsd/freebsd/blob/8103b0ddb041617b7cd161528f0ff93ff32970a2/include/regex.h
- NetBSD: https://github.com/NetBSD/src/blob/61c8f6fbb7e38b20e862d5cb3ed2203312963283/include/regex.h

This adds the defines from include/uapi/asm-generic/hugetlb_encode.h and the corresponding defines in include/uapi/linux/mman.h to linux_like/linux/gnu/mod.rs and the equivalent for musl in linux_like/linux/musl/mod.rs

Solves #1700

Removes two defines from musl/b32/hexagon.rs that are now provided two mudules "up"

The `fanotify` API[0] is a linux-specific API for notification and interception
of filesystem events. In some ways it is similar to `inotify`, but with
different advantages/tradeoffs. It is particularly well suited to full
filesystem/mount monitoring (vs per directory) and for allowing/denying access
to files (`inotify` lacks this capability).

The `fanotify` API has been updated several times since it was enabled in Linux
2.6.37. Presently I've only included support for the original `fanotify`
features, and the `FAN_MARK_FILESYSTEM` addition made in Linux 4.20. There are
subsequent updates in 5.0 and 5.1 not covered in this initial commit.

This commit adds the relevant constants and types from
`uapi/linux/fanotify.h`[1] and two new functions (`fanotify_init`[2] and
`fanotify_wrap`[3]) to `src/unix/linux_like/linux/mod.rs`. While I believe this
API is also present on Android I have presently limited my attention to Linux.

Although this commit focuses on Linux 4.20.x's `fanotify` API/constants I have
skipped adding constants for `FAN_ALL_CLASS_BITS`, `FAN_ALL_INIT_FLAGS`,
`FAN_ALL_MARK_FLAGS`, `FAN_ALL_EVENTS`, `FAN_ALL_PERM_EVENTS` and
`FAN_ALL_OUTGOING_EVENTS` even though they are present in this kernel version's
headers. These defines were deprecated[4] in later releases with instructions to
not use them in new programs or extend them with new values. It would be a shame
for new Rust programs to use deprecated #defines!

[0]: http://man7.org/linux/man-pages/man7/fanotify.7.html
[1]: https://github.com/torvalds/linux/blob/d54f4fba889b205e9cd8239182ca5d27d0ac3bc2/include/uapi/linux/fanotify.h
[2]: http://man7.org/linux/man-pages/man2/fanotify_init.2.html
[3]: http://man7.org/linux/man-pages/man2/fanotify_mark.2.html
[4]: https://github.com/torvalds/linux/commit/23c9deeb3285d34fd243abb3d6b9f07db60c3cf4#diff-4c9ca62be6bf38cc08f7ea9daf16e379

This is a Linux-only feature that was already present as a
syscall. Add it just to linux/gnu for the moment, as the musl version
bundled in the Rust's x86_64-unknown-linux-musl toolchain doesn't
include it yet.

Signed-off-by: Sergio Lopez <slp@redhat.com>