[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4683D78E.6080309@goop.org>
Date: Thu, 28 Jun 2007 11:45:18 -0400
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Roman Zippel <zippel@...ux-m68k.org>
CC: "Eric W. Biederman" <ebiederm@...ssion.com>,
lkml <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Arch <linux-arch@...r.kernel.org>,
Al Viro <viro@....linux.org.uk>
Subject: Re: [PATCH] cross-architecture ELF clean up
Roman Zippel wrote:
> This could be avoided by reordering things within elf.h, but is it really
> necessary since there is no user of this right now?
>
Well, yes, I don't have much need to include ELF headers in asm now, but
I still think its worth separating the arch-specific definitions from
asm/elf.h and all the other stuff they pull in. Specifically, the
structure forward declarations and constants have very few external
dependencies, but the structure definitions - particularly the
arch-specific ones - have very wide dependencies, which is what I'm
trying to solve. Very few pieces of code care about the arch-specific
structures.
> module.h does indeed pull in way too much, but instead of hacking headers
> into little pieces, IMO it would be better to solve the real problem.
>
No, that's not the real problem; its a side-effect of the real problem.
The real problem is that linux/elf.h ends up bringing in too much.
arch/powerpc, for example, has its own stripped down copy of elf.h for
bootloader stuff in order to avoid this extra crud. The fix is to make
it possible to get just the appropriate ELF definitions without getting
everything else.
There's the secondary problem that lots of ELF stuff is copy'n'paste
duplicated across all the architectures, but all they really care about
is one of two sets of parallel definitions (32 or 64 ELF structures).
That was the secondary
> I played with it a little and the patch below moves a lot stuff out of
> module.h, so this would drastically reduce the header dependencies.
> Unless there are major objections, I can test the patch a little more and
> convert the other archs.
>
Well, it seems like a large fiddly patch which only solves part of the
problem I want to solve; actually it doesn't help me at all, but it
achieves one of the side-effects of my patch. The arch changes make it
look pretty awkward to merge.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists