linux-kernel - Re: [GIT PULL] x86: use arch/x86/include

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]

Date:	Wed, 30 Jul 2008 11:35:22 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Ingo Molnar <mingo@...e.hu>, Sam Ravnborg <sam@...nborg.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jeff Dike <jdike@...toit.com>
Subject: Re: [GIT PULL] x86: use arch/x86/include

On Wed, 30 Jul 2008, H. Peter Anvin wrote:
> 
> Git *should* be able to track those changes across a rename and even with a
> rename on one branch and changes on another; in my experience it works well
> for filename renames, but git doesn't understand directory renames at all, so
> new files do have to be moved to their new locations manually.

Yes. Note that this is true only for merging (and some operations that can 
use the merge infrastructure, like cherry-picking). It's obviously not 
true for pure patches that are just pending in mailboxes etc.

The big x86 architecture rename (i386->x86) had some problems just due to 
the huge number of files involved, but the include directory should not 
just be easier, on the git side we also fixed some of the scalability 
issues we had with lots of renames.

[ However, fairly old versions of git may still have trouble due to 
  limiting rename detection to a smallish number of files (ie 100 or 
  something).

  Note, though, that the only person who needs a reasonably modern version 
  of git is the person actually doing any merges that take renames into 
  account. So "normal users" can use old versions without even realising. 

  And we're really talking about git versions about a year old - the whole 
  arch/x86 rename thing was June last year. So by "modern" I definitely 
  don't mean "last week", but "updated in any kind of reasonable manner", 
  which I assume everybody involved in any x86 merging would have ]

> > I missed the discussion on this, what's the point of renaming all these
> > files?
> 
> I know there has been talk about this on and off for a long time (to get all
> the arch code into arch/).  I don't know if there are any mechanical reasons
> for it, on top of that.

My big reason is that it makes it much easier for me to see when merges 
only touch a specific architecture (git will always sort things by 
pathname, so if the first pathname is arch/xyz/something and the last one 
is arch/xyz/somethingelse, then I don't even need to look any closer). It 
also makes it much nicer for my statistics generator.

IOW, it helps the "overview" people, probably not so much anybody else. 

It also ends up allowing some extra flexibility, ie we can put 
architecture header files in other places than <asm/xyz.h> (eg the whole 
<mach/xyz.h> thing), so there _are_ technical reasons for it, but at least 
to me those are just frosting on the cake.

			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/