usr/include: openrisc: don't HDRTEST bpf_perf_event.h

Since openrisc does not support PERF_EVENTS, omit the HDRTEST of
bpf_perf_event.h for arch/openrisc/.

Fixes a build error:
usr/include/linux/bp

usr/include: openrisc: don't HDRTEST bpf_perf_event.h

Since openrisc does not support PERF_EVENTS, omit the HDRTEST of
bpf_perf_event.h for arch/openrisc/.

Fixes a build error:
usr/include/linux/bpf_perf_event.h:14:28: error: field 'regs' has incomplete type

Signed-off-by: Randy Dunlap <[email protected]>
Acked-by: Stafford Horne <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: hdrcheck: fix cross build with clang

The headercheck tries to call clang with a mix of compiler arguments
that don't include the target architecture. When building e.g. x86
headers on arm64,

kbuild: hdrcheck: fix cross build with clang

The headercheck tries to call clang with a mix of compiler arguments
that don't include the target architecture. When building e.g. x86
headers on arm64, this produces a warning like

clang: warning: unknown platform, assuming -mfloat-abi=soft

Add in the KBUILD_CPPFLAGS, which contain the target, in order to make it
build properly.

See also 1b71c2fb04e7 ("kbuild: userprogs: fix bitsize and target
detection on clang").

Reviewed-by: Nathan Chancellor <[email protected]>
Fixes: feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS")
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

kbuild: Drop support for include/asm-<arch> in headers_check.pl

"include/asm-<arch>" was replaced by "arch/<arch>/include/asm" a long
time ago. All assembler header files are now included using
"#i

kbuild: Drop support for include/asm-<arch> in headers_check.pl

"include/asm-<arch>" was replaced by "arch/<arch>/include/asm" a long
time ago. All assembler header files are now included using
"#include <asm/*>", so there is no longer a need to rewrite paths.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: use $(src) instead of $(srctree)/$(src) for source directory

Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention withou

kbuild: use $(src) instead of $(srctree)/$(src) for source directory

Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:

src := $(obj)

When the kernel is built in a separate output directory, $(src) does
not accurately reflect the source directory location. While Kbuild
resolves this discrepancy by specifying VPATH=$(srctree) to search for
source files, it does not cover all cases. For example, when adding a
header search path for local headers, -I$(srctree)/$(src) is typically
passed to the compiler.

This introduces inconsistency between upstream and downstream Makefiles
because $(src) is used instead of $(srctree)/$(src) for the latter.

To address this inconsistency, this commit changes the semantics of
$(src) so that it always points to the directory in the source tree.

Going forward, the variables used in Makefiles will have the following
meanings:

$(obj) - directory in the object tree
$(src) - directory in the source tree (changed by this commit)
$(objtree) - the top of the kernel object tree
$(srctree) - the top of the kernel source tree

Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
with $(src).

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

arch: Remove Itanium (IA-64) architecture

The Itanium architecture is obsolete, and an informal survey [0] reveals
that any residual use of Itanium hardware in production is mostly HP-UX
or OpenVMS

arch: Remove Itanium (IA-64) architecture

The Itanium architecture is obsolete, and an informal survey [0] reveals
that any residual use of Itanium hardware in production is mostly HP-UX
or OpenVMS based. The use of Linux on Itanium appears to be limited to
enthusiasts that occasionally boot a fresh Linux kernel to see whether
things are still working as intended, and perhaps to churn out some
distro packages that are rarely used in practice.

None of the original companies behind Itanium still produce or support
any hardware or software for the architecture, and it is listed as
'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers
that contributed on behalf of those companies (nor anyone else, for that
matter) have been willing to support or maintain the architecture
upstream or even be responsible for applying the odd fix. The Intel
firmware team removed all IA-64 support from the Tianocore/EDK2
reference implementation of EFI in 2018. (Itanium is the original
architecture for which EFI was developed, and the way Linux supports it
deviates significantly from other architectures.) Some distros, such as
Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have
dropped support years ago.

While the argument is being made [1] that there is a 'for the common
good' angle to being able to build and run existing projects such as the
Grid Community Toolkit [2] on Itanium for interoperability testing, the
fact remains that none of those projects are known to be deployed on
Linux/ia64, and very few people actually have access to such a system in
the first place. Even if there were ways imaginable in which Linux/ia64
could be put to good use today, what matters is whether anyone is
actually doing that, and this does not appear to be the case.

There are no emulators widely available, and so boot testing Itanium is
generally infeasible for ordinary contributors. GCC still supports IA-64
but its compile farm [3] no longer has any IA-64 machines. GLIBC would
like to get rid of IA-64 [4] too because it would permit some overdue
code cleanups. In summary, the benefits to the ecosystem of having IA-64
be part of it are mostly theoretical, whereas the maintenance overhead
of keeping it supported is real.

So let's rip off the band aid, and remove the IA-64 arch code entirely.
This follows the timeline proposed by the Debian/ia64 maintainer [5],
which removes support in a controlled manner, leaving IA-64 in a known
good state in the most recent LTS release. Other projects will follow
once the kernel support is removed.

[0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/
[1] https://lore.kernel.org/all/[email protected]/
[2] https://gridcf.org/gct-docs/latest/index.html
[3] https://cfarm.tetaneutral.net/machines/list/
[4] https://lore.kernel.org/all/[email protected]/
[5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/

Acked-by: Tony Luck <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>

show more ...

sparc: add asm/stat.h to UAPI compile-test coverage

asm/stat.h is currently excluded from the UAPI compile-test for
ARCH=sparc because of the errors like follows:

In file included from <command-l

sparc: add asm/stat.h to UAPI compile-test coverage

asm/stat.h is currently excluded from the UAPI compile-test for
ARCH=sparc because of the errors like follows:

In file included from <command-line>:
./usr/include/asm/stat.h:11:2: error: unknown type name 'ino_t'
11 | ino_t st_ino;
| ^~~~~
HDRTEST usr/include/asm/param.h
./usr/include/asm/stat.h:12:2: error: unknown type name 'mode_t'
12 | mode_t st_mode;
| ^~~~~~
./usr/include/asm/stat.h:14:2: error: unknown type name 'uid_t'
14 | uid_t st_uid;
| ^~~~~
./usr/include/asm/stat.h:15:2: error: unknown type name 'gid_t'
15 | gid_t st_gid;
| ^~~~~

The errors can be fixed by prefixing the types with __kernel_.

Then, remove the no-header-test entry from user/include/Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>

show more ...

powerpc: add asm/stat.h to UAPI compile-test coverage

asm/stat.h is currently excluded from the UAPI compile-test for
ARCH=powerpc because of the errors like follows:

HDRTEST usr/include/asm/st

powerpc: add asm/stat.h to UAPI compile-test coverage

asm/stat.h is currently excluded from the UAPI compile-test for
ARCH=powerpc because of the errors like follows:

HDRTEST usr/include/asm/stat.h
In file included from <command-line>:32:
./usr/include/asm/stat.h:32:2: error: unknown type name 'ino_t'
32 | ino_t st_ino;
| ^~~~~
./usr/include/asm/stat.h:35:2: error: unknown type name 'mode_t'
35 | mode_t st_mode;
| ^~~~~~
./usr/include/asm/stat.h:40:2: error: unknown type name 'uid_t'
40 | uid_t st_uid;
| ^~~~~
./usr/include/asm/stat.h:41:2: error: unknown type name 'gid_t'
41 | gid_t st_gid;
| ^~~~~

The errors can be fixed by prefixing the types with __kernel_.

Then, remove the no-header-test entry from user/include/Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>

show more ...

mips: add asm/stat.h to UAPI compile-test coverage

asm/stat.h is currently excluded from the UAPI compile-test for
ARCH=mips because of the errors like follows:

HDRTEST usr/include/asm/stat.h

mips: add asm/stat.h to UAPI compile-test coverage

asm/stat.h is currently excluded from the UAPI compile-test for
ARCH=mips because of the errors like follows:

HDRTEST usr/include/asm/stat.h
In file included from <command-line>:32:
./usr/include/asm/stat.h:22:2: error: unknown type name 'ino_t'
22 | ino_t st_ino;
| ^~~~~
./usr/include/asm/stat.h:23:2: error: unknown type name 'mode_t'
23 | mode_t st_mode;
| ^~~~~~
./usr/include/asm/stat.h:25:2: error: unknown type name 'uid_t'
25 | uid_t st_uid;
| ^~~~~
./usr/include/asm/stat.h:26:2: error: unknown type name 'gid_t'
26 | gid_t st_gid;
| ^~~~~
./usr/include/asm/stat.h:58:2: error: unknown type name 'mode_t'
58 | mode_t st_mode;
| ^~~~~~
./usr/include/asm/stat.h:61:2: error: unknown type name 'uid_t'
61 | uid_t st_uid;
| ^~~~~
./usr/include/asm/stat.h:62:2: error: unknown type name 'gid_t'
62 | gid_t st_gid;
| ^~~~~

The errors can be fixed by prefixing the types with __kernel_.

Then, remove the no-header-test entry from user/include/Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>

show more ...

riscv: add linux/bpf_perf_event.h to UAPI compile-test coverage

I can compile this for ARCH=riscv with CONFIG_UAPI_HEADER_TEST=y.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by

riscv: add linux/bpf_perf_event.h to UAPI compile-test coverage

I can compile this for ARCH=riscv with CONFIG_UAPI_HEADER_TEST=y.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>

show more ...

kbuild: prevent exported headers from including <stdlib.h>, <stdbool.h>

Some UAPI headers included <stdlib.h>, like this:

#ifndef __KERNEL__
#include <stdlib.h>
#endif

As it turned out, they

kbuild: prevent exported headers from including <stdlib.h>, <stdbool.h>

Some UAPI headers included <stdlib.h>, like this:

#ifndef __KERNEL__
#include <stdlib.h>
#endif

As it turned out, they just included it for no good reason.

After some fixes, now I can compile-test UAPI headers
(CONFIG_UAPI_HEADER_TEST=y) without including <stdlib.h> from the
system header search paths.

To avoid somebody getting it back again, this commit adds the dummy
header, usr/dummy-include/stdlib.h

I added $(srctree)/usr/dummy-include to the header search paths.
Because it is searched before the system directories, if someone
tries to include <stdlib.h>, they will see the error message.

While I am here, I also replaced $(objtree)/usr/include with $(obj),
but it has no functional change.

If we can make kernel headers self-contained (that is, none of exported
kernel headers includes system headers), we will be able to add the
-nostdinc flag, but that is much far from where we stand now.

As a realistic solution, we can ban header inclusion individually by
putting a dummy header into usr/dummy-include/.

Currently, no header include <stdbool.h>. I put it as well before somebody
attempts to use it.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>

show more ...

kbuild: uapi: use -fsyntax-only rather than -S

The UAPI header tests are checking that the generated headers do not
have syntax errors. There's no need to run the rest of the compilation
pipeline af

kbuild: uapi: use -fsyntax-only rather than -S

The UAPI header tests are checking that the generated headers do not
have syntax errors. There's no need to run the rest of the compilation
pipeline after semantic analysis has run. Replace -S -o /dev/null with
-fsyntax-only.

Signed-off-by: Nick Desaulniers <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: add --target to correctly cross-compile UAPI headers with Clang

When you compile-test UAPI headers (CONFIG_UAPI_HEADER_TEST=y) with
Clang, they are currently compiled for the host target (li

kbuild: add --target to correctly cross-compile UAPI headers with Clang

When you compile-test UAPI headers (CONFIG_UAPI_HEADER_TEST=y) with
Clang, they are currently compiled for the host target (likely x86_64)
regardless of the given ARCH=.

In fact, some exported headers include libc headers. For example,
include/uapi/linux/agpgart.h includes <stdlib.h> after being exported.
The header search paths should match to the target we are compiling
them for.

Pick up the --target triple from KBUILD_CFLAGS in the same ways as
commit 7f58b487e9ff ("kbuild: make Clang build userprogs for target
architecture").

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>

show more ...

usr/include: replace extra-y with always-y

extra-y is not run for 'make modules'. The header compile test should
be executed irrespective of the build target. always-y is a better fit.

Signed-off-b

usr/include: replace extra-y with always-y

extra-y is not run for 'make modules'. The header compile test should
be executed irrespective of the build target. always-y is a better fit.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

reiserfs_xattr.h: add linux/reiserfs_xattr.h to UAPI compile-test coverage

linux/reiserfs_xattr.h is currently excluded from the UAPI compile-test
because of the error like follows:

HDRTEST usr

reiserfs_xattr.h: add linux/reiserfs_xattr.h to UAPI compile-test coverage

linux/reiserfs_xattr.h is currently excluded from the UAPI compile-test
because of the error like follows:

HDRTEST usr/include/linux/reiserfs_xattr.h
In file included from <command-line>:
./usr/include/linux/reiserfs_xattr.h:22:9: error: unknown type name ‘size_t’
22 | size_t length;
| ^~~~~~

The error can be fixed by replacing size_t with __kernel_size_t.

Then, remove the no-header-test entry from user/include/Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

kexec.h: add linux/kexec.h to UAPI compile-test coverage

linux/kexec.h is currently excluded from the UAPI compile-test because
of the errors like follows:

HDRTEST usr/include/linux/kexec.h
I

kexec.h: add linux/kexec.h to UAPI compile-test coverage

linux/kexec.h is currently excluded from the UAPI compile-test because
of the errors like follows:

HDRTEST usr/include/linux/kexec.h
In file included from <command-line>:
./usr/include/linux/kexec.h:56:9: error: unknown type name ‘size_t’
56 | size_t bufsz;
| ^~~~~~
./usr/include/linux/kexec.h:58:9: error: unknown type name ‘size_t’
58 | size_t memsz;
| ^~~~~~

The errors can be fixed by replacing size_t with __kernel_size_t.

Then, remove the no-header-test entry from user/include/Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

fsmap.h: add linux/fsmap.h to UAPI compile-test coverage

linux/fsmap.h is currently excluded from the UAPI compile-test because
of the error like follows:

HDRTEST usr/include/linux/fsmap.h
In

fsmap.h: add linux/fsmap.h to UAPI compile-test coverage

linux/fsmap.h is currently excluded from the UAPI compile-test because
of the error like follows:

HDRTEST usr/include/linux/fsmap.h
In file included from <command-line>:
./usr/include/linux/fsmap.h:72:19: error: unknown type name ‘size_t’
72 | static __inline__ size_t
| ^~~~~~

The error can be fixed by replacing size_t with __kernel_size_t.

Then, remove the no-header-test entry from user/include/Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

android/binder.h: add linux/android/binder(fs).h to UAPI compile-test coverage

linux/android/binder.h and linux/android/binderfs.h are currently
excluded from the UAPI compile-test because of the er

android/binder.h: add linux/android/binder(fs).h to UAPI compile-test coverage

linux/android/binder.h and linux/android/binderfs.h are currently
excluded from the UAPI compile-test because of the errors like follows:

HDRTEST usr/include/linux/android/binder.h
In file included from <command-line>:
./usr/include/linux/android/binder.h:291:9: error: unknown type name ‘pid_t’
291 | pid_t sender_pid;
| ^~~~~
./usr/include/linux/android/binder.h:292:9: error: unknown type name ‘uid_t’
292 | uid_t sender_euid;
| ^~~~~

The errors can be fixed by replacing {pid,uid}_t with __kernel_{pid,uid}_t.

Then, remove the no-header-test entries from user/include/Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

shmbuf.h: add asm/shmbuf.h to UAPI compile-test coverage

asm/shmbuf.h is currently excluded from the UAPI compile-test because of
the errors like follows:

HDRTEST usr/include/asm/shmbuf.h
In

shmbuf.h: add asm/shmbuf.h to UAPI compile-test coverage

asm/shmbuf.h is currently excluded from the UAPI compile-test because of
the errors like follows:

HDRTEST usr/include/asm/shmbuf.h
In file included from ./usr/include/asm/shmbuf.h:6,
from <command-line>:
./usr/include/asm-generic/shmbuf.h:26:33: error: field ‘shm_perm’ has incomplete type
26 | struct ipc64_perm shm_perm; /* operation perms */
| ^~~~~~~~
./usr/include/asm-generic/shmbuf.h:27:9: error: unknown type name ‘size_t’
27 | size_t shm_segsz; /* size of segment (bytes) */
| ^~~~~~
./usr/include/asm-generic/shmbuf.h:40:9: error: unknown type name ‘__kernel_pid_t’
40 | __kernel_pid_t shm_cpid; /* pid of creator */
| ^~~~~~~~~~~~~~
./usr/include/asm-generic/shmbuf.h:41:9: error: unknown type name ‘__kernel_pid_t’
41 | __kernel_pid_t shm_lpid; /* pid of last operator */
| ^~~~~~~~~~~~~~

The errors can be fixed by replacing size_t with __kernel_size_t and by
including proper headers.

Then, remove the no-header-test entry from user/include/Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

signal.h: add linux/signal.h and asm/signal.h to UAPI compile-test coverage

linux/signal.h and asm/signal.h are currently excluded from the UAPI
compile-test because of the errors like follows:

signal.h: add linux/signal.h and asm/signal.h to UAPI compile-test coverage

linux/signal.h and asm/signal.h are currently excluded from the UAPI
compile-test because of the errors like follows:

HDRTEST usr/include/asm/signal.h
In file included from <command-line>:
./usr/include/asm/signal.h:103:9: error: unknown type name ‘size_t’
103 | size_t ss_size;
| ^~~~~~

The errors can be fixed by replacing size_t with __kernel_size_t.

Then, remove the no-header-test entries from user/include/Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

kbuild: Add environment variables for userprogs flags

Allow additional arguments be passed to userprogs compilation.
Reproducible clang builds need to provide a sysroot and gcc path to
ensure the sa

kbuild: Add environment variables for userprogs flags

Allow additional arguments be passed to userprogs compilation.
Reproducible clang builds need to provide a sysroot and gcc path to
ensure the same toolchain is used across hosts. KCFLAGS is not currently
used for any user programs compilation, so add new USERCFLAGS and
USERLDFLAGS which serves similar purpose as HOSTCFLAGS/HOSTLDFLAGS.

Clang might detect GCC installation on hosts which have it installed
to a default location in /. With addition of these environment
variables, you can specify flags such as:

$ make USERCFLAGS=--sysroot=/path/to/sysroot

This can also be used to specify different sysroots such as musl or
bionic which may be installed on the host in paths that the compiler
may not search by default.

Signed-off-by: Elliot Berman <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Reviewed-by: Fangrui Song <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: remove include/linux/cyclades.h from header file check

The file now rightfully throws up a big warning that it should never be
included, so remove it from the header_check test.

Fixes: f236

kbuild: remove include/linux/cyclades.h from header file check

The file now rightfully throws up a big warning that it should never be
included, so remove it from the header_check test.

Fixes: f23653fe6447 ("tty: Partially revert the removal of the Cyclades public API")
Cc: stable <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: "Maciej W. Rozycki" <[email protected]>
Reported-by: Stephen Rothwell <[email protected]>
Reported-by: kernel test robot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usr/include/Makefile: add linux/nfc.h to the compile-test coverage

As linux/nfc.h userspace compilation was finally fixed by commits
79b69a83705e ("nfc: uapi: use kernel size_t to fix user-space bui

usr/include/Makefile: add linux/nfc.h to the compile-test coverage

As linux/nfc.h userspace compilation was finally fixed by commits
79b69a83705e ("nfc: uapi: use kernel size_t to fix user-space builds")
and 7175f02c4e5f ("uapi: fix linux/nfc.h userspace compilation errors"),
there is no need to keep the compile-test exception for it in
usr/include/Makefile.

Signed-off-by: Dmitry V. Levin <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: move headers_check.pl to usr/include/

This script is only used by usr/include/Makefile. Make it local to
the directory.

Update the comment in include/uapi/linux/soundcard.h because
'make he

kbuild: move headers_check.pl to usr/include/

This script is only used by usr/include/Makefile. Make it local to
the directory.

Update the comment in include/uapi/linux/soundcard.h because
'make headers_check' is no longer functional.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

arch: ia64: Remove rest of perfmon support

Perfmon support (used by oprofile earlier) was removed by commit
ecf5b72d5f66 ("ia64: Remove perfmon") earlier, but it missed few files
to remove/update.

arch: ia64: Remove rest of perfmon support

Perfmon support (used by oprofile earlier) was removed by commit
ecf5b72d5f66 ("ia64: Remove perfmon") earlier, but it missed few files
to remove/update.

Clean it up.

Suggested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Acked-by: Robert Richter <[email protected]>
Acked-by: William Cohen <[email protected]>
Acked-by: Al Viro <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>

show more ...

unexport linux/elfcore.h

It's unusable from userland - it uses elf_gregset_t, which is not
provided by exported headers. glibc has it in sys/procfs.h, but
the same file defines struct elf_prstatus,

unexport linux/elfcore.h

It's unusable from userland - it uses elf_gregset_t, which is not
provided by exported headers. glibc has it in sys/procfs.h, but
the same file defines struct elf_prstatus, so linux/elfcore.h can't
be included once sys/procfs.h has been pulled. Same goes for uclibc
and dietlibc simply doesn't have elf_gregset_t defined anywhere.

IOW, no userland source is including that thing.

Signed-off-by: Al Viro <[email protected]>

show more ...