lists.openwall.net   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  linux-hardening  linux-cve-announce  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]
Message-ID: <alpine.LFD.1.10.0805211635040.3081@woody.linux-foundation.org>
Date:	Wed, 21 May 2008 16:51:57 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Paul Mackerras <paulus@...ba.org>
cc:	Takashi Iwai <tiwai@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: Moving include/asm-* [was: Re: Moving sound/* to drivers/ ?]



On Thu, 22 May 2008, Paul Mackerras wrote:
>
> Linus Torvalds writes:
> 
> > Me personally, I've been more irritated by include/asm-xyz vs arch/xyz. It 
> > would be so nice if all the arch-specific changes woudl always show up 
> > under arch/ (both from a statistics standpoint, and just because then a 
> > diffstat really shows arch-specific stuff really obviously, and sorts all 
> > the arch-specific stuff together).
> 
> We could git mv include/asm-xyz arch/xyz/asm and then arrange to pass
> -Iarch/$(ARCH) to gcc.

That would work, but there's a few alternatives that I think would work 
even better.

The downside with what you suggest is that I'd like the arch-specific 
include files to be clearly separated (ie I think the naming should be 
"something/include/something", which makes things clearer. 

Also, I hate how doing '-Iarch/$(ARCH)' would basically make any random 
arch/xyz/ subdirectory be a potential location for a header file. I'd hate 
for the include-path to contain subdirectories that simply aren't meant 
for that (ie #include <kernel/tls.h> would now quite by mistake find the 
*private* header file in arch/x86/kernel/tls.h that was never meant to be 
generally visible!)

So the trivial alternative is to just do

	git mv include/asm-xyz arch/xyz/include

and keep the symlink that we already set up (just make it point to 
arch/xyz/include instead of include/asm-xyz). That is conceptually the 
smallest change.

But the alternative I'd actually *prefer* would avoid the symlink, and 
would be roughly:

	for i in $(arch-list)
	do
		mkdir arch/$i/include
		git mv include/asm-$i arch/$i/asm
		
	done
	git mv include/asm-generic include/asm

and then remove the symlink to asm entirely, and instead add a 
-Iarch/xyz/include, and put that as the *first* entry in the include path.

This would mean that:

 - no symlink games

 - if some architecture just uses the generic header file, it doesn't need 
   to do anything: it just wouldn't implement that header file at all, and 
   the next entry in the search-path would just find the generic 
   include/asm entry.

I dunno. It's not a huge deal, but it really would be nice to have all the 
arch/xyz code together for diffstat's etc.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ