lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 28 Jun 2007 11:45:18 -0400
From:	Jeremy Fitzhardinge <>
To:	Roman Zippel <>
CC:	"Eric W. Biederman" <>,
	lkml <>,
	Andrew Morton <>,
	Linux Arch <>,
	Al Viro <>
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 

> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists