* Sam Ravnborg <sam@ravnborg.org> wrote:
[color=blue]
> Hi x86 guys.
>
> It turned out to be easy to enable um to use arch/x86/include so here
> is a git pull.[/color]

hm, we have a _ton_ of changes to include files queued up already, so
this is rather inconvenient.

I missed the discussion on this, what's the point of renaming all these
files?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

07-30-2008, 06:30 PM

unix

Re: [GIT PULL] x86: use arch/x86/include

Ingo Molnar wrote:[color=blue]
> * Sam Ravnborg <sam@ravnborg.org> wrote:
>[color=green]
>> Hi x86 guys.
>>
>> It turned out to be easy to enable um to use arch/x86/include so here
>> is a git pull.[/color]
>
> hm, we have a _ton_ of changes to include files queued up already, so
> this is rather inconvenient.[/color]

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.
[color=blue]
> I missed the discussion on this, what's the point of renaming all these
> files?[/color]

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.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

07-30-2008, 06:40 PM

unix

Re: [GIT PULL] x86: use arch/x86/include

* H. Peter Anvin <hpa@zytor.com> wrote:
[color=blue]
> Ingo Molnar wrote:[color=green]
>> * Sam Ravnborg <sam@ravnborg.org> wrote:
>>[color=darkred]
>>> Hi x86 guys.
>>>
>>> It turned out to be easy to enable um to use arch/x86/include so here
>>> is a git pull.[/color]
>>
>> hm, we have a _ton_ of changes to include files queued up already, so
>> this is rather inconvenient.[/color]
>
> 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.[/color]

yes, it copes in some cases - but i've had rather bad experiences with
it.

the reason i raised this is because i tried to pull Sam's renames, and
they created 48 conflicts.
[color=blue][color=green]
>> I missed the discussion on this, what's the point of renaming all these
>> files?[/color]
>
> 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.[/color]

hm, seems rather pointless to me, i thought there might be some better
reasons for it. Historically we've put all include files into
include/asm-* - why upset the decade-long status quo now without strong
technical reasons?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

07-30-2008, 06:40 PM

unix

Re: [GIT PULL] x86: use arch/x86/include

On Wed, 30 Jul 2008, H. Peter Anvin wrote:[color=blue]
>
> 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.[/color]

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 ]
[color=blue][color=green]
> > I missed the discussion on this, what's the point of renaming all these
> > files?[/color]
>
> 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.[/color]

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 [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

07-30-2008, 06:50 PM

unix

Re: [GIT PULL] x86: use arch/x86/include

On Wed, Jul 30, 2008 at 08:04:11PM +0200, Ingo Molnar wrote:[color=blue]
>
> * Sam Ravnborg <sam@ravnborg.org> wrote:
>[color=green]
> > Hi x86 guys.
> >
> > It turned out to be easy to enable um to use arch/x86/include so here
> > is a git pull.[/color]
>
> hm, we have a _ton_ of changes to include files queued up already, so
> this is rather inconvenient.[/color]
git should cope with this if changes come in via git. I do not
know about "git am" applied patches.
[color=blue]
>
> I missed the discussion on this, what's the point of renaming all these
> files?[/color]

It has been discussed many times to keep arch and arch include files
under arch/.
Lately Linus outlined this:

I took the ball and did the kbuild side of this so we could do this
gradually.
sparc are already converted. sh has it ready to be pulled and others
are playing with it.

How we do it in the best way for such a fragile codebase as x86 is
I am not sure. I would assume to do it late in the merge window where
the minimum set of patches are queued up would be best (and this is now).

And Linus already said he would like to take it sooner.
Quote:

====================================================================
On Tue, 29 Jul 2008, Sam Ravnborg wrote:[color=blue]
>
> But will you accept this stuff now or will we have to wait until
> next merge window?[/color]

if the patches are really small adn the resulting build is well tested
(ignoring the actual _move_ operation), I'm ok with taking them.

In fact, in many ways I'd _prefer_ to do it now, rather than have it
pending and then do it durign the next merge window when there are a lot
of non-movement changes too.
====================================================================

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

07-30-2008, 07:20 PM

unix

Re: [GIT PULL] x86: use arch/x86/include

* Sam Ravnborg <sam@ravnborg.org> wrote:
[color=blue][color=green]
> > hm, we have a _ton_ of changes to include files queued up already,
> > so this is rather inconvenient.[/color]
>
> git should cope with this if changes come in via git. I do not know
> about "git am" applied patches.[/color]

the pending commits are ordinary commits and there's little difference
between a leaf commit that came via git and one that came via emails.

(the difference between Git and email is for more complex ops like
renames, merges - i.e. more abstract and multi-commit operations.)

But such more complex scenarios are not what i'm talking about. We've
got this many leaf commits in include/asm-x86/ at the moment:

308 files changed, 3025 insertions(+), 2025 deletions(-)

.... and pulling your rename generates almost 50 conflicts. (Also, i've
got to hunt down all scripts that somehow rely on the location on
include/asm-x86.)
[color=blue][color=green]
> > I missed the discussion on this, what's the point of renaming all
> > these files?[/color]
>
> It has been discussed many times to keep arch and arch include files
> under arch/.
> Lately Linus outlined this:
>
> [url]http://kerneltrap.org/mailarchive/linux-kernel/2008/5/21/1903924[/url]
>
> I took the ball and did the kbuild side of this so we could do this
> gradually.
>
> sparc are already converted. sh has it ready to be pulled and others
> are playing with it.
>
> How we do it in the best way for such a fragile codebase as x86 is I
> am not sure. [...][/color]

huh, fragile codebase? Is that a flamebait? :-) What do you mean
exactly?

The timing problems come from the fact that 90% of Linux development and
95% of Linux testing happens on x86. So we've already got a ton of stuff
queued up for the next merge window. (and some cleanups for this cycle
as well)

But fortunately you've scripted all this, so i guess we can do it at any
stage. Could you send the script we should run?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

07-30-2008, 07:30 PM

unix

Re: [GIT PULL] x86: use arch/x86/include

Ingo Molnar wrote:[color=blue]
>
> But fortunately you've scripted all this, so i guess we can do it at any
> stage. Could you send the script we should run?
>[/color]

That's really the sanest way to deal with all this. If this is already
automated, then we can script-generate a roving (constantly rebased)
pseudo-branch, and apply it formally before pushing it up to Linus.

Restructuring changes are hideously messy, because they're orthogonal to
everything else that's going on. The x86 merge itself and all that went
along with it is a great example.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

07-30-2008, 07:50 PM

unix

Re: [GIT PULL] x86: use arch/x86/include

> >[color=blue][color=green]
> > How we do it in the best way for such a fragile codebase as x86 is I
> > am not sure. [...][/color]
>
> huh, fragile codebase? Is that a flamebait? :-) What do you mean
> exactly?[/color]
I only wanted to say that x86 see more changes than any other arch
in the kernel like you also nicely says below.[color=blue]
>
> The timing problems come from the fact that 90% of Linux development and
> 95% of Linux testing happens on x86. So we've already got a ton of stuff
> queued up for the next merge window. (and some cleanups for this cycle
> as well)
>
> But fortunately you've scripted all this, so i guess we can do it at any
> stage. Could you send the script we should run?[/color]

It is a combination of a scrip and a patch.
The script:
#####
set -e
for D in include/asm-x86/mach-*; do
echo $D
DD=$(echo $D | cut -d '-' -f 3)
mkdir -p arch/x86/include/mach-$DD/arch
git mv include/asm-x86/mach-$DD/* arch/x86/include/mach-$DD
rmdir include/asm-x86/mach-$DD
done

So um needs a few more changes to build.
And ia64 needs a fix too.
Documentation is trivial and can be done in a seperate commit.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

07-31-2008, 11:20 PM

unix

Re: [GIT PULL] x86: use arch/x86/include

So is there a better or worse time to move the include files?

At the end of a merge window would seem to be
the least disruptive time. So we can either hit this
now, or wait until the next merge.

-Tony

[Just did the ia64 move locally with no apparent problems, should I
commit and send a "please pull"?]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

07-31-2008, 11:20 PM

unix

Re: [GIT PULL] x86: use arch/x86/include

Tony Luck wrote:[color=blue]
> So is there a better or worse time to move the include files?
>
> At the end of a merge window would seem to be
> the least disruptive time. So we can either hit this
> now, or wait until the next merge.
>
> -Tony
>
> [Just did the ia64 move locally with no apparent problems, should I
> commit and send a "please pull"?][/color]

That is clearly the least disruptive time; that's also when we did the
x86 rename.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]