It seems cleanest to just put all the constants in one place rather than
scatter them around based on how they happen to be used.
I want to be able to include a header to get just the ELF type and
constant definitions with no other crud. Both arch-independent ELF
definitions, and the ones parameterised by ELF_CLASS.
I want this for three reasons:
1. one is the general cleanup that allows people to use
forward-declared ELF types in general kernel headers without
needing to pull in the full set of ELF headers
2. and to be able to pull full ELF declarations into code which can't
deal with Linux headers, such as bootloader code which doesn't
compile in the same universe as the rest of the kernel
3. a way of getting arch-dependent but broadly common ELF parameters
in a consistent way
This is complicated by the fact that each architecture needs to define
some arch-dependent ELF structures which will end up having wider
dependencies. The classic example is the ELF note for core files which
contains register and other process state, and that will naturally pull
in a bunch of other headers to implement that. Unfortunately, the
current structure of the ELF headers mean that any user with the
slightest interest in ELF structures will end up pulling in half the
kernel headers via the asm/elf.h includes.
So my solution was to factor the ELF definitions into useful groups that
allow the various users to pull in what they need. The breakdown is:
* arch-independent ELF forward declarations: linux/elf-decl.h
* arch-independent constants: linux/elf-const.h
* arch-independent ELF structure definitions: linux/elf-defn.h
* arch-parameterised ELF declarations: asm/elf-defines.h
and because more or less all the architectures do the same thing for
their parameterised ELF types (albeit inconsistently), I pulled the
implementation into asm-generic/elf{32,64}-defines.h, and the typical
asm/elf-defines.h ends up being a single line to include the appropriate
one.
I'd agree that linux/elf-const.h and linux/elf-decl.h could probably be
folded together.
Which architecture? The variation of other includes in the various
asm-*/elf.h headers is very broad.
On i386, it ends up being dependent on the mach-* subarch mess, which
doesn't work in the boot code. Since there's nothing about the ELF
definitions which is subarch-dependent, so that's clearly a bogus
dependency.
Yes, but it does get a bit subtle. x86-64 does strange things with
redefining the ELF class to compile a 32-bit binfmt_elf, and I think
other architectures play similar games. Rearranging these headers is
pretty fragile, and I think my approach is a bit less likely to
(possibly) break things. But I haven't cross-compiled all the
architectures, so I may have broken stuff anyway.
Yes, but only for the module.h case. My concerns are wider.
J
-
