public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Arch <linux-arch@vger.kernel.org>,
	Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [PATCH] cross-architecture ELF clean up
Date: Thu, 28 Jun 2007 11:45:18 -0400	[thread overview]
Message-ID: <4683D78E.6080309@goop.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0706280027100.4890@scrub.home>

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


  reply	other threads:[~2007-06-28 18:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070620230854.246399397@goop.org>
2007-06-20 23:08 ` [PATCH] cross-architecture ELF clean up Jeremy Fitzhardinge
2007-06-21  8:20   ` ian
2007-06-21 15:06     ` Jeremy Fitzhardinge
2007-06-21 16:49   ` Chris Zankel
2007-06-21 18:31     ` Jeremy Fitzhardinge
2007-06-25  9:02   ` David Woodhouse
2007-06-25 12:43     ` Jeremy Fitzhardinge
2007-06-25 13:40     ` Roman Zippel
2007-06-25 13:56       ` Clemens Koller
2007-06-25 14:06         ` Roman Zippel
2007-06-25 13:37   ` Roman Zippel
2007-06-26 19:29     ` Jeremy Fitzhardinge
2007-06-27 23:25       ` Roman Zippel
2007-06-28 15:45         ` Jeremy Fitzhardinge [this message]
2007-06-28 21:48           ` Roman Zippel
2007-06-29 14:53             ` Jeremy Fitzhardinge
2007-06-29 18:12               ` Sam Ravnborg
2007-07-01 16:23                 ` Jeremy Fitzhardinge
2007-06-25 15:18   ` Roman Zippel
2007-06-26 19:28     ` Jeremy Fitzhardinge
2007-06-29  4:13   ` Paul Mackerras
2007-06-29  5:31     ` Jeremy Fitzhardinge
2007-06-29  4:48   ` Paul Mackerras
2007-06-29  5:31     ` Jeremy Fitzhardinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4683D78E.6080309@goop.org \
    --to=jeremy@goop.org \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ftp.linux.org.uk \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox