subject:"\[RFC, Announce\] Unified x86 architecture, arch\/x86"

* Brian Gerst <[EMAIL PROTECTED]> wrote:

> > And there is more of that, when you take the time and look closely 
> > at the _32.[ch] _64.[ch] files which are created by the merge.
> 
> Looking at the include files, many more are near-identical in trivial 
> ways, such as whitespace, comments, local variable names, or guard 
> #ifdefs.

yeah. And by moving them next to each other, people actually have the 
real incentive to look and ponder: "these two files do similar things 
but they look so different. Does it _have_ to be so?". Often the answer 
is: no, it could really be shared.

And even when things will continue to be different, it's nice to have 
them side by side for documentation purposes as well. "we do this 
differently on 64-bit, because ...".

Key to starting all these cleanups is to create plain and simple 
physical proximity - and our transition arch/x86 and include/asm-x86 
achieves that - nothing more, nothing less.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Brian Gerst

Thomas Gleixner wrote:
> On Sat, 2007-07-21 at 07:37 +0200, Andi Kleen wrote: 
>> On Saturday 21 July 2007 00:32, Thomas Gleixner wrote:
>>> As an initial matter, we made it painstakingly sure that the resulting
>>> .o files in a 32-bit build are bit for bit equal.
>> You got not a single line less code duplication then, so i don't really
>> see the point of this.
> 
> Really ? 
> 
> The script detected 15 identical files with a simple cmp.
> 
> It also unified another 10 by simply looking at the only line in there
> "include "
> 
> And there is more of that, when you take the time and look closely at
> the _32.[ch] _64.[ch] files which are created by the merge.

Looking at the include files, many more are near-identical in trivial
ways, such as whitespace, comments, local variable names, or guard #ifdefs.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

Thanks for doing this, it's definitely the way to go.

After a quick look over it, I noted a small mistake:
After the arch/x86_64/kernel/Makefile -> arch/x86/kernel/Makefile_64 
transition, the three foo-$(subst m,y,$(CONFIG_BAR)) got replaced with
foo-$(CONFIG_BAR).

Although the subst's look fishy, such changes shouldn't be part of the 
architecture merge.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread David Woodhouse

On Sat, 2007-07-21 at 00:32 +0200, Thomas Gleixner wrote:
> We are pleased to announce a project we've been working on for some 
> time: the unified x86 architecture tree, or "arch/x86" - and we'd like
> to solicit feedback about it. 

Oooh, shiny. We've been talking about how useful this would be for
years. Experience with the unification of PowerPC shows that it's
definitely the right thing to do -- it reduces the number of gratuitous
differences between 32-bit and 64-bit code, and makes it far more easier
to ensure that bug-fixes and new features get added to both at the same
time.

> When should this go upstream?
> -
> 
> We actually think that the sooner we get over with this, the better.

I'm inclined to agree.

-- 
dwmw2

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Rusty Russell

On Sat, 2007-07-21 at 10:15 +0200, Thomas Gleixner wrote:
> On Sat, 2007-07-21 at 07:37 +0200, Andi Kleen wrote: 
> > On Saturday 21 July 2007 00:32, Thomas Gleixner wrote:
> > > We are pleased to announce a project we've been working on for some
> > > time: the unified x86 architecture tree, or "arch/x86" - and we'd like
> > > to solicit feedback about it.
> > 
> > Well you know my position on this. I think it's a bad idea because
> > it means we can never get rid of any old junk. IMNSHO arch/x86_64
> > is significantly cleaner and simpler in many ways than arch/i386 and I would
> > like to preserve that. Also in general arch/x86_64 is much easier to hack
> > than arch/i386 because it's easier to regression test and in general
> > has to care about much less junk. And I don't 
> > know of any way to ever fix that for i386 besides splitting the old
> > stuff off completely.
> 
> I disagree of course. 
> 
> I worked on both trees quite intensive over the last years and I broke
> x86_64 more than once when hacking on i386 and vice versa. 

Me too.

At the very least I'd like to see asm-x86/ for headers used by both.

That said, the merge is exactly as I'd have done it.  So if this were a
democracy, I'd vote in favour.

Cheers,
Rusty.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


* Andi Kleen <[EMAIL PROTECTED]> wrote:

> > It happens so often that someone accidentally breaks one 
> > architecture because he didn't notice the code also gets used on the 
> > other architecture.
> 
> That's not changing at all. Especially with even more sharing, (than I 
> think would be prudent) like Thomas treated, you'll likely have to 
> test compile both for most changes.

yes, very much so, and that's exactly one of our points.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Saturday 21 July 2007 10:15:50 Thomas Gleixner wrote:

> 
> The script detected 15 identical files with a simple cmp.

You mean 


arch/i386/boot/.gitignore
arch/i386/boot/tools/.gitignore
arch/i386/oprofile/Kconfig
include/asm-i386/poll.h
include/asm-i386/emergency-restart.h
include/asm-i386/spinlock_types.h
include/asm-i386/vga.h
include/asm-i386/msidef.h
include/asm-i386/hypertransport.h
include/asm-i386/ioctl.h
include/asm-i386/fcntl.h

? 

[of which several just #include http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Sat, 2007-07-21 at 07:37 +0200, Andi Kleen wrote: 
> On Saturday 21 July 2007 00:32, Thomas Gleixner wrote:
> > We are pleased to announce a project we've been working on for some
> > time: the unified x86 architecture tree, or "arch/x86" - and we'd like
> > to solicit feedback about it.
> 
> Well you know my position on this. I think it's a bad idea because
> it means we can never get rid of any old junk. IMNSHO arch/x86_64
> is significantly cleaner and simpler in many ways than arch/i386 and I would
> like to preserve that. Also in general arch/x86_64 is much easier to hack
> than arch/i386 because it's easier to regression test and in general
> has to care about much less junk. And I don't 
> know of any way to ever fix that for i386 besides splitting the old
> stuff off completely.

I disagree of course. 

I worked on both trees quite intensive over the last years and I broke
x86_64 more than once when hacking on i386 and vice versa. 

Your "junk" argument is nothing else than a strawman which you beat on
every time when this discussion comes up.

> Besides radical file movements like this are bad anyways. They cause
> a big break in patchkits and forward/backwards porting that doesn't 
> really help anybody.

Interestingly enough the folks with the big patch kits (Virtualization)
would be quite happy about that move.

> > This causes double maintenance
> > even for functionality that is conceptually the same for the 32-bit and
> > the 64-bit tree. (such as support for standard PC platform architecture
> > devices)
> 
> It's not really the same platform: one is PC hardware going back forever
> with zillions of bugs, the other is modern PC platforms which much less
> bugs and quirks

It _IS_ the same platform. x86_64 is PC hardware with zillions of bugs
as well. And it is not modern at all. It is nothing else than a 64 bit
version of the legacy x86.

> To see it otherwise it's more a junkification of arch/x86_64 than
> a cleanup of arch/i386 -- in fact you didn't really clean up arch/i386 
> at all.

We went for a 1 : 1 replacement without merging anything which is not
obvious in the first place (identical files and files, which are just
including some other file). That way we were able to do a binary
compatible migration.

The clean up is the next step and there are enough folks out there
willing to help on this.

> > As an initial matter, we made it painstakingly sure that the resulting
> > .o files in a 32-bit build are bit for bit equal.
> 
> You got not a single line less code duplication then, so i don't really
> see the point of this.

Really ? 

The script detected 15 identical files with a simple cmp.

It also unified another 10 by simply looking at the only line in there
"include "

And there is more of that, when you take the time and look closely at
the _32.[ch] _64.[ch] files which are created by the merge.

tglx

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Sat, 2007-07-21 at 09:42 +0200, Andi Kleen wrote:
> > 
> > It happens so often that someone accidentally breaks one architecture 
> > because he didn't notice the code also gets used on the other 
> > architecture.
> 
> That's not changing at all. Especially with even more sharing, (than I think
> would be prudent) like Thomas treated, you'll likely have to test compile both
> for most changes.

And a shared code base makes it entirely clear, that you must recheck
bot ARCHs when you touch code in there. 

Right now it is not clear at all.

tglx


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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Sat, Jul 21, 2007 at 09:42:48AM +0200, Andi Kleen wrote:
> On Saturday 21 July 2007 09:35:33 Adrian Bunk wrote:
> 
> > The problem with the current "merging" is that it's extremely hard to 
> > figure out whether some code in x86_64 might be using some code in i386 
> > since there are currently 5 (five) different mechanisms used for sharing 
> > code between the two architectures.
> > 
> > It happens so often that someone accidentally breaks one architecture 
> > because he didn't notice the code also gets used on the other 
> > architecture.
> 
> That's not changing at all. Especially with even more sharing, (than I think
> would be prudent) like Thomas treated, you'll likely have to test compile both
> for most changes.

It's not about compilation, it's about seeing that this code might be 
shared.

When e.g. changing a file under arch/i386/kernel/cpu/mtrr/ it's highly 
surprising that this file might also be used on x86_64.

> -Andi

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Saturday 21 July 2007 09:35:33 Adrian Bunk wrote:

> The problem with the current "merging" is that it's extremely hard to 
> figure out whether some code in x86_64 might be using some code in i386 
> since there are currently 5 (five) different mechanisms used for sharing 
> code between the two architectures.
> 
> It happens so often that someone accidentally breaks one architecture 
> because he didn't notice the code also gets used on the other 
> architecture.

That's not changing at all. Especially with even more sharing, (than I think
would be prudent) like Thomas treated, you'll likely have to test compile both
for most changes.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Sat, Jul 21, 2007 at 08:06:11AM +0200, Andi Kleen wrote:
> On Saturday 21 July 2007 07:50:46 Steven Rostedt wrote:
>  
> > This patch was the beginning of the merger, not the end result. It strived
> > for binary identical images. It was to put everything together as a
> > _starting_point_!   The next thing to do after this is to start the
> > merging.
> 
> Well we've been merging what makes sense since several years. So it's not 
> really starting anything that hasn't already occurred.

The problem with the current "merging" is that it's extremely hard to 
figure out whether some code in x86_64 might be using some code in i386 
since there are currently 5 (five) different mechanisms used for sharing 
code between the two architectures.

It happens so often that someone accidentally breaks one architecture 
because he didn't notice the code also gets used on the other 
architecture.

> -Andi

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Avi Kivity

Thomas Gleixner wrote:
> We are pleased to announce a project we've been working on for some 
> time: the unified x86 architecture tree, or "arch/x86" - and we'd like 
> to solicit feedback about it.
>   

kvm will really like this.  while kvm will always have #ifdefs for i386
and x86_64, this work will reduce them, and will make kvm code cleaner. 
Of course, I also believe it makes sense from the non-kvm-centric point
of view.

Thanks for doing this!

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


> > It's not really the same platform: one is PC hardware going back forever
> > with zillions of bugs, the other is modern PC platforms which much less
> > bugs and quirks
> 
> hehe, I'm seeing a bunch of bugs and quirks appear.  It's just that
> x86_64 isn't as old as i386 to have as many of them. But give it time.

It will always fundamentally always have less bugs and quirks than i386 because
it's much younger. Modern x86 is significantly different than traditional x86
and in the old days hardware wasn't really tested for the now modern interfaces,
so they tended to have a lot of bugs and quirks.

-Andi

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Saturday 21 July 2007 07:50:46 Steven Rostedt wrote:
 
> This patch was the beginning of the merger, not the end result. It strived
> for binary identical images. It was to put everything together as a
> _starting_point_!   The next thing to do after this is to start the
> merging.

Well we've been merging what makes sense since several years. So it's not 
really starting anything that hasn't already occurred.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Steven Rostedt

On Sat, 21 Jul 2007, Andi Kleen wrote:

> On Saturday 21 July 2007 00:32, Thomas Gleixner wrote:
> > We are pleased to announce a project we've been working on for some
> > time: the unified x86 architecture tree, or "arch/x86" - and we'd like
> > to solicit feedback about it.
>
> Well you know my position on this. I think it's a bad idea because
> it means we can never get rid of any old junk. IMNSHO arch/x86_64
> is significantly cleaner and simpler in many ways than arch/i386 and I would
> like to preserve that. Also in general arch/x86_64 is much easier to hack
> than arch/i386 because it's easier to regression test and in general
> has to care about much less junk. And I don't
> know of any way to ever fix that for i386 besides splitting the old
> stuff off completely.

I have to say honestly that it is much easier to work in the i386 arch
directories than the x86_64. But that may be my own feelings.  You seem to
have a nice style that you like and think that it is cleaner. But it
doesn't really seem much cleaner to me. Somethings I like better with the
x86_64 code, and there's somethings I like better with the i386 code. But
from a comfort level, I have to go with worknig with the i386 code.

>
> Besides radical file movements like this are bad anyways. They cause
> a big break in patchkits and forward/backwards porting that doesn't
> really help anybody.

I think it helps a lot of people. Especially those that are trying to add
things to _both_ i386 and x86_64.

>
> > This causes double maintenance
> > even for functionality that is conceptually the same for the 32-bit and
> > the 64-bit tree. (such as support for standard PC platform architecture
> > devices)

Not sure what you mean here?  I would think that we have this "double
maintence" anyway.  Fixes that are done in x86_64 probably should also be
done in i386.  Why have it in two places?

>
> It's not really the same platform: one is PC hardware going back forever
> with zillions of bugs, the other is modern PC platforms which much less
> bugs and quirks

hehe, I'm seeing a bunch of bugs and quirks appear.  It's just that
x86_64 isn't as old as i386 to have as many of them. But give it time.

>
> To see it otherwise it's more a junkification of arch/x86_64 than
> a cleanup of arch/i386 -- in fact you didn't really clean up arch/i386
> at all.

That was not the point of this patch. This patch was to unify the two so
that we can get started on the unification.

>
> > How did we do it?
> > -
> >
> > As an initial matter, we made it painstakingly sure that the resulting
> > .o files in a 32-bit build are bit for bit equal.
>
> You got not a single line less code duplication then, so i don't really
> see the point of this.
>

Did you read what tglx wrote?  The point of this patch was to keep
everything the _same_.  The fact that not a single line less code
duplication is a feature.  A great starting point where we can easily
trace things back to the current arch separation, as well as move forward
in merging the two.

-- Steve

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Steven Rostedt


On Sat, 21 Jul 2007, Andi Kleen wrote:

 On Saturday 21 July 2007 00:32, Thomas Gleixner wrote:
  We are pleased to announce a project we've been working on for some
  time: the unified x86 architecture tree, or arch/x86 - and we'd like
  to solicit feedback about it.

 Well you know my position on this. I think it's a bad idea because
 it means we can never get rid of any old junk. IMNSHO arch/x86_64
 is significantly cleaner and simpler in many ways than arch/i386 and I would
 like to preserve that. Also in general arch/x86_64 is much easier to hack
 than arch/i386 because it's easier to regression test and in general
 has to care about much less junk. And I don't
 know of any way to ever fix that for i386 besides splitting the old
 stuff off completely.

I have to say honestly that it is much easier to work in the i386 arch
directories than the x86_64. But that may be my own feelings.  You seem to
have a nice style that you like and think that it is cleaner. But it
doesn't really seem much cleaner to me. Somethings I like better with the
x86_64 code, and there's somethings I like better with the i386 code. But
from a comfort level, I have to go with worknig with the i386 code.



 Besides radical file movements like this are bad anyways. They cause
 a big break in patchkits and forward/backwards porting that doesn't
 really help anybody.

I think it helps a lot of people. Especially those that are trying to add
things to _both_ i386 and x86_64.


  This causes double maintenance
  even for functionality that is conceptually the same for the 32-bit and
  the 64-bit tree. (such as support for standard PC platform architecture
  devices)

Not sure what you mean here?  I would think that we have this double
maintence anyway.  Fixes that are done in x86_64 probably should also be
done in i386.  Why have it in two places?


 It's not really the same platform: one is PC hardware going back forever
 with zillions of bugs, the other is modern PC platforms which much less
 bugs and quirks

hehe, I'm seeing a bunch of bugs and quirks appear.  It's just that
x86_64 isn't as old as i386 to have as many of them. But give it time.


 To see it otherwise it's more a junkification of arch/x86_64 than
 a cleanup of arch/i386 -- in fact you didn't really clean up arch/i386
 at all.

That was not the point of this patch. This patch was to unify the two so
that we can get started on the unification.


  How did we do it?
  -
 
  As an initial matter, we made it painstakingly sure that the resulting
  .o files in a 32-bit build are bit for bit equal.

 You got not a single line less code duplication then, so i don't really
 see the point of this.


Did you read what tglx wrote?  The point of this patch was to keep
everything the _same_.  The fact that not a single line less code
duplication is a feature.  A great starting point where we can easily
trace things back to the current arch separation, as well as move forward
in merging the two.

-- Steve

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Saturday 21 July 2007 07:50:46 Steven Rostedt wrote:
 
 This patch was the beginning of the merger, not the end result. It strived
 for binary identical images. It was to put everything together as a
 _starting_point_!   The next thing to do after this is to start the
 merging.

Well we've been merging what makes sense since several years. So it's not 
really starting anything that hasn't already occurred.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


  It's not really the same platform: one is PC hardware going back forever
  with zillions of bugs, the other is modern PC platforms which much less
  bugs and quirks
 
 hehe, I'm seeing a bunch of bugs and quirks appear.  It's just that
 x86_64 isn't as old as i386 to have as many of them. But give it time.

It will always fundamentally always have less bugs and quirks than i386 because
it's much younger. Modern x86 is significantly different than traditional x86
and in the old days hardware wasn't really tested for the now modern interfaces,
so they tended to have a lot of bugs and quirks.

-Andi

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Avi Kivity

Thomas Gleixner wrote:
 We are pleased to announce a project we've been working on for some 
 time: the unified x86 architecture tree, or arch/x86 - and we'd like 
 to solicit feedback about it.
   

kvm will really like this.  while kvm will always have #ifdefs for i386
and x86_64, this work will reduce them, and will make kvm code cleaner. 
Of course, I also believe it makes sense from the non-kvm-centric point
of view.

Thanks for doing this!

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Sat, Jul 21, 2007 at 08:06:11AM +0200, Andi Kleen wrote:
 On Saturday 21 July 2007 07:50:46 Steven Rostedt wrote:
  
  This patch was the beginning of the merger, not the end result. It strived
  for binary identical images. It was to put everything together as a
  _starting_point_!   The next thing to do after this is to start the
  merging.
 
 Well we've been merging what makes sense since several years. So it's not 
 really starting anything that hasn't already occurred.

The problem with the current merging is that it's extremely hard to 
figure out whether some code in x86_64 might be using some code in i386 
since there are currently 5 (five) different mechanisms used for sharing 
code between the two architectures.

It happens so often that someone accidentally breaks one architecture 
because he didn't notice the code also gets used on the other 
architecture.

 -Andi

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Saturday 21 July 2007 09:35:33 Adrian Bunk wrote:

 The problem with the current merging is that it's extremely hard to 
 figure out whether some code in x86_64 might be using some code in i386 
 since there are currently 5 (five) different mechanisms used for sharing 
 code between the two architectures.
 
 It happens so often that someone accidentally breaks one architecture 
 because he didn't notice the code also gets used on the other 
 architecture.

That's not changing at all. Especially with even more sharing, (than I think
would be prudent) like Thomas treated, you'll likely have to test compile both
for most changes.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Sat, Jul 21, 2007 at 09:42:48AM +0200, Andi Kleen wrote:
 On Saturday 21 July 2007 09:35:33 Adrian Bunk wrote:
 
  The problem with the current merging is that it's extremely hard to 
  figure out whether some code in x86_64 might be using some code in i386 
  since there are currently 5 (five) different mechanisms used for sharing 
  code between the two architectures.
  
  It happens so often that someone accidentally breaks one architecture 
  because he didn't notice the code also gets used on the other 
  architecture.
 
 That's not changing at all. Especially with even more sharing, (than I think
 would be prudent) like Thomas treated, you'll likely have to test compile both
 for most changes.

It's not about compilation, it's about seeing that this code might be 
shared.

When e.g. changing a file under arch/i386/kernel/cpu/mtrr/ it's highly 
surprising that this file might also be used on x86_64.

 -Andi

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Sat, 2007-07-21 at 07:37 +0200, Andi Kleen wrote: 
 On Saturday 21 July 2007 00:32, Thomas Gleixner wrote:
  We are pleased to announce a project we've been working on for some
  time: the unified x86 architecture tree, or arch/x86 - and we'd like
  to solicit feedback about it.
 
 Well you know my position on this. I think it's a bad idea because
 it means we can never get rid of any old junk. IMNSHO arch/x86_64
 is significantly cleaner and simpler in many ways than arch/i386 and I would
 like to preserve that. Also in general arch/x86_64 is much easier to hack
 than arch/i386 because it's easier to regression test and in general
 has to care about much less junk. And I don't 
 know of any way to ever fix that for i386 besides splitting the old
 stuff off completely.

I disagree of course. 

I worked on both trees quite intensive over the last years and I broke
x86_64 more than once when hacking on i386 and vice versa. 

Your junk argument is nothing else than a strawman which you beat on
every time when this discussion comes up.

 Besides radical file movements like this are bad anyways. They cause
 a big break in patchkits and forward/backwards porting that doesn't 
 really help anybody.

Interestingly enough the folks with the big patch kits (Virtualization)
would be quite happy about that move.

  This causes double maintenance
  even for functionality that is conceptually the same for the 32-bit and
  the 64-bit tree. (such as support for standard PC platform architecture
  devices)
 
 It's not really the same platform: one is PC hardware going back forever
 with zillions of bugs, the other is modern PC platforms which much less
 bugs and quirks

It _IS_ the same platform. x86_64 is PC hardware with zillions of bugs
as well. And it is not modern at all. It is nothing else than a 64 bit
version of the legacy x86.

 To see it otherwise it's more a junkification of arch/x86_64 than
 a cleanup of arch/i386 -- in fact you didn't really clean up arch/i386 
 at all.

We went for a 1 : 1 replacement without merging anything which is not
obvious in the first place (identical files and files, which are just
including some other file). That way we were able to do a binary
compatible migration.

The clean up is the next step and there are enough folks out there
willing to help on this.

  As an initial matter, we made it painstakingly sure that the resulting
  .o files in a 32-bit build are bit for bit equal.
 
 You got not a single line less code duplication then, so i don't really
 see the point of this.

Really ? 

The script detected 15 identical files with a simple cmp.

It also unified another 10 by simply looking at the only line in there
include the other arch/file

And there is more of that, when you take the time and look closely at
the _32.[ch] _64.[ch] files which are created by the merge.

tglx


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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Sat, 2007-07-21 at 09:42 +0200, Andi Kleen wrote:
  
  It happens so often that someone accidentally breaks one architecture 
  because he didn't notice the code also gets used on the other 
  architecture.
 
 That's not changing at all. Especially with even more sharing, (than I think
 would be prudent) like Thomas treated, you'll likely have to test compile both
 for most changes.

And a shared code base makes it entirely clear, that you must recheck
bot ARCHs when you touch code in there. 

Right now it is not clear at all.

tglx


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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Saturday 21 July 2007 10:15:50 Thomas Gleixner wrote:

 
 The script detected 15 identical files with a simple cmp.

You mean 


arch/i386/boot/.gitignore
arch/i386/boot/tools/.gitignore
arch/i386/oprofile/Kconfig
include/asm-i386/poll.h
include/asm-i386/emergency-restart.h
include/asm-i386/spinlock_types.h
include/asm-i386/vga.h
include/asm-i386/msidef.h
include/asm-i386/hypertransport.h
include/asm-i386/ioctl.h
include/asm-i386/fcntl.h

? 

[of which several just #include asm-generic/foo.h] ? 

I suppose msidef.h and hypertransport.h should be shared agreed; 
for the others it is not obvious. spinlock_types will likely fork soon;
it used to be different in the past already and will be again.

-Andi

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


* Andi Kleen [EMAIL PROTECTED] wrote:

  It happens so often that someone accidentally breaks one 
  architecture because he didn't notice the code also gets used on the 
  other architecture.
 
 That's not changing at all. Especially with even more sharing, (than I 
 think would be prudent) like Thomas treated, you'll likely have to 
 test compile both for most changes.

yes, very much so, and that's exactly one of our points.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Rusty Russell

On Sat, 2007-07-21 at 10:15 +0200, Thomas Gleixner wrote:
 On Sat, 2007-07-21 at 07:37 +0200, Andi Kleen wrote: 
  On Saturday 21 July 2007 00:32, Thomas Gleixner wrote:
   We are pleased to announce a project we've been working on for some
   time: the unified x86 architecture tree, or arch/x86 - and we'd like
   to solicit feedback about it.
  
  Well you know my position on this. I think it's a bad idea because
  it means we can never get rid of any old junk. IMNSHO arch/x86_64
  is significantly cleaner and simpler in many ways than arch/i386 and I would
  like to preserve that. Also in general arch/x86_64 is much easier to hack
  than arch/i386 because it's easier to regression test and in general
  has to care about much less junk. And I don't 
  know of any way to ever fix that for i386 besides splitting the old
  stuff off completely.
 
 I disagree of course. 
 
 I worked on both trees quite intensive over the last years and I broke
 x86_64 more than once when hacking on i386 and vice versa. 

Me too.

At the very least I'd like to see asm-x86/ for headers used by both.

That said, the merge is exactly as I'd have done it.  So if this were a
democracy, I'd vote in favour.

Cheers,
Rusty.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread David Woodhouse

On Sat, 2007-07-21 at 00:32 +0200, Thomas Gleixner wrote:
 We are pleased to announce a project we've been working on for some 
 time: the unified x86 architecture tree, or arch/x86 - and we'd like
 to solicit feedback about it. 

Oooh, shiny. We've been talking about how useful this would be for
years. Experience with the unification of PowerPC shows that it's
definitely the right thing to do -- it reduces the number of gratuitous
differences between 32-bit and 64-bit code, and makes it far more easier
to ensure that bug-fixes and new features get added to both at the same
time.

 When should this go upstream?
 -
 
 We actually think that the sooner we get over with this, the better.

I'm inclined to agree.

-- 
dwmw2

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

Thanks for doing this, it's definitely the way to go.

After a quick look over it, I noted a small mistake:
After the arch/x86_64/kernel/Makefile - arch/x86/kernel/Makefile_64 
transition, the three foo-$(subst m,y,$(CONFIG_BAR)) got replaced with
foo-$(CONFIG_BAR).

Although the subst's look fishy, such changes shouldn't be part of the 
architecture merge.

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Brian Gerst

Thomas Gleixner wrote:
 On Sat, 2007-07-21 at 07:37 +0200, Andi Kleen wrote: 
 On Saturday 21 July 2007 00:32, Thomas Gleixner wrote:
 As an initial matter, we made it painstakingly sure that the resulting
 .o files in a 32-bit build are bit for bit equal.
 You got not a single line less code duplication then, so i don't really
 see the point of this.
 
 Really ? 
 
 The script detected 15 identical files with a simple cmp.
 
 It also unified another 10 by simply looking at the only line in there
 include the other arch/file
 
 And there is more of that, when you take the time and look closely at
 the _32.[ch] _64.[ch] files which are created by the merge.

Looking at the include files, many more are near-identical in trivial
ways, such as whitespace, comments, local variable names, or guard #ifdefs.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


* Brian Gerst [EMAIL PROTECTED] wrote:

  And there is more of that, when you take the time and look closely 
  at the _32.[ch] _64.[ch] files which are created by the merge.
 
 Looking at the include files, many more are near-identical in trivial 
 ways, such as whitespace, comments, local variable names, or guard 
 #ifdefs.

yeah. And by moving them next to each other, people actually have the 
real incentive to look and ponder: these two files do similar things 
but they look so different. Does it _have_ to be so?. Often the answer 
is: no, it could really be shared.

And even when things will continue to be different, it's nice to have 
them side by side for documentation purposes as well. we do this 
differently on 64-bit, because 

Key to starting all these cleanups is to create plain and simple 
physical proximity - and our transition arch/x86 and include/asm-x86 
achieves that - nothing more, nothing less.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Glauber de Oliveira Costa


On 7/21/07, Andi Kleen [EMAIL PROTECTED] wrote:

[of which several just #include asm-generic/foo.h] ?

I suppose msidef.h and hypertransport.h should be shared agreed;
for the others it is not obvious. spinlock_types will likely fork soon;
it used to be different in the past already and will be again.

Why will it fork? I don't think it will ever happen that the trees
will have large pieces that _has_ to be different one from the other.
So if it's forking to achieve some benefits, why can't i386 get the
benefits too? I think this is the whole point here.

Surely as it is today (and just because it wasn't merged earlier and
the past!), the x86_64 tree has a bunch of things that are quite
better structured than the i386 (and maybe vice-versa, but I must
admit that unlike Steven Roasted, I like the x86_64 a lot more). But
in the long term,  it tends to just get the best of each picked up.

And oh yeah, i386 is older, has a lot more corner cases, but even if
it does count against the merge, we have a net win at the end.


--
Glauber de Oliveira Costa.
Free as in Freedom
http://glommer.net

The less confident you are, the more serious you have to act.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Arjan van de Ven


 Besides radical file movements like this are bad anyways. They cause
 a big break in patchkits and forward/backwards porting that doesn't 
 really help anybody.

Sorry Andi but I strongly disagree with your disapproval of this.


for existing out of tree patches it's not a big break, it's one sed
script away (until consolidation happens).

For distro backports... well that's a distro problem; the distros get
paid to do that work by their customers. We really can't hold back
mainline progress for that

Having one tree is a lot of progress; it means we (Intel and the rest of
the kernel community) only have to add features, bugfixes and quirks to
one place. It means testing is shared. It means feature sets are shared.

The only argument against is but there are quirks in the old one that I
don't want to see.. well Thomas solves that by having a clean way to do
per 32/64 files for the few cases where it's needed.


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

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

Fwd: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread . .

-- Forwarded message --
From: . . [EMAIL PROTECTED]
Date: Jul 21, 2007 11:08 PM
Subject: [RFC, Announce] Unified x86 architecture, arch/x86
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]

Hi all!

[please CC me]

I think, for this time is te good, for starting the 2.7-tree. I know,
thet is the old question, but has everything in his favour:
* arch unifie (i386 + x86_84 - x86)
* new virtualisation technik (xen, kvm, lguest)
* new FS (ext4, reiser4)
* new cpu-scheduler (CFS)
* soo many patch in -mm tree
* subsystem modifications

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Oleg Verych

* From: Alan Cox
* Date: Sat, 21 Jul 2007 00:55:12 +0100
* Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, 
Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a 
Lloegr o'r rhif cofrestru 3798903

 On Fri, 20 Jul 2007 18:38:39 -0400
 Jeff Garzik [EMAIL PROTECTED] wrote:

 I agree with Andi...  it's quite nice to be able to leave some arch/i386 
 stuff, and not carry it over to arch/x86-64.

 Its easy enough to push that stuff into arch/x86/legacy and have one
 subdirectory of stuff to pull in for ancient systems.

Or if i386 and virualization guys don't want to quietly break/mess with
stuff pulled by x86-64, move it to x86-64 instead. Elegant, easy, honors
Andi.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Matt Mackall

On Sat, Jul 21, 2007 at 12:32:59AM +0200, Thomas Gleixner wrote:
 How is the new arch/x86 and include/asm-x86 namespace layed out? Our 
 foremost concern was to enable a 100% smooth transition to the new, 
 shared architecture, while still enabling much more fine-grained future 
 unification of the source code. To do this we consciously aimed for the 
 strictest possible unification strategy: we only 'unified' those source 
 files that are already bit for bit equal between the two architectures 
 today. For all other files we used the following rule: if a file came 
 from arch/i386/foo/bar.c, it gets moved to arch/x86/foo/bar_32.c, if it 
 came from arch/x86_64/foo/bar.c it gets moved to arch/x86/foo/bar_64.c. 
 We also generated arch/x86/foo/bar.c that simply #include's those two 
 files (depending on whether we do a 32-bit or a 64-bit built). If a file 
 only existed in only one of the architectures, it's moved to 
 arch/x86/foo/bar.c straight away. (take a look at our git repository to 
 see how this works out in practice.)

Can we see some stats on:

How many files were auto-merged?
How many files got 32.c and 64.c extensions?
How many existed only in one arch?

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-21 Thread Chris Wright

* Matt Mackall ([EMAIL PROTECTED]) wrote:
 Can we see some stats on:
 
 How many files were auto-merged?
 How many files got 32.c and 64.c extensions?
 How many existed only in one arch?

It's mostly about file movement first.

 Kbuild |8 +-
 Makefile   |   23 +-
 arch/i386/Kconfig  | 1275 +-
 arch/i386/Makefile |  208 +--
 arch/i386/kernel/early_printk.c|2 -
 arch/i386/kernel/tsc_sync.c|1 -
 arch/x86/Kconfig   | 1919 
 arch/{i386 = x86}/Kconfig.cpu |0 
 arch/{i386 = x86}/Kconfig.debug   |   50 +-
 arch/x86/Kconfig_32| 1283 +
 arch/{i386/Kconfig.debug = x86/Kconfig_32.debug}  |0 
 arch/x86/Kconfig_64|  792 
 .../{x86_64/Kconfig.debug = x86/Kconfig_64.debug} |0 
 arch/x86/Makefile  |5 +
 arch/{i386 = x86}/Makefile.cpu|0 
 arch/x86/Makefile_32   |  163 ++
 arch/x86/Makefile_64   |  128 ++
 arch/{i386 = x86}/boot/.gitignore |0 
 arch/{i386 = x86}/boot/Makefile   |6 +-
 arch/{i386 = x86}/boot/a20.c  |0 
 arch/{i386 = x86}/boot/apm.c  |0 
 arch/{i386 = x86}/boot/bitops.h   |0 
 arch/{i386 = x86}/boot/boot.h |0 
 arch/{i386 = x86}/boot/cmdline.c  |0 
 arch/{i386 = x86}/boot/code16gcc.h|0 
 arch/{i386 = x86}/boot/compressed/.gitignore  |0 
 arch/x86/boot/compressed/Makefile  |5 +
 .../Makefile = x86/boot/compressed/Makefile_32}   |8 +-
 .../Makefile = x86/boot/compressed/Makefile_64}   |8 +-
 .../head.S = x86/boot/compressed/head_32.S}   |0 
 .../head.S = x86/boot/compressed/head_64.S}   |0 
 .../misc.c = x86/boot/compressed/misc_32.c}   |0 
 .../misc.c = x86/boot/compressed/misc_64.c}   |0 
 arch/{i386 = x86}/boot/compressed/relocs.c|0 
 .../boot/compressed/vmlinux_32.lds}|0 
 .../boot/compressed/vmlinux_32.scr}|0 
 .../boot/compressed/vmlinux_64.lds}|0 
 .../boot/compressed/vmlinux_64.scr}|0 
 arch/{i386 = x86}/boot/copy.S |0 
 arch/{i386 = x86}/boot/cpu.c  |0 
 arch/{i386 = x86}/boot/cpucheck.c |0 
 arch/{i386 = x86}/boot/edd.c  |0 
 arch/{i386 = x86}/boot/header.S   |0 
 arch/{i386 = x86}/boot/install.sh |0 
 arch/{i386 = x86}/boot/main.c |0 
 arch/{i386 = x86}/boot/mca.c  |0 
 arch/{i386 = x86}/boot/memory.c   |0 
 arch/{i386 = x86}/boot/mtools.conf.in |0 
 arch/{i386 = x86}/boot/pm.c   |0 
 arch/{i386 = x86}/boot/pmjump.S   |0 
 arch/{i386 = x86}/boot/printf.c   |0 
 arch/x86/boot/setup.S  |7 +
 arch/{i386 = x86}/boot/setup.ld   |0 
 arch/{i386 = x86}/boot/string.c   |0 
 arch/{i386 = x86}/boot/tools/.gitignore   |0 
 arch/{i386 = x86}/boot/tools/build.c  |0 
 arch/{i386 = x86}/boot/tty.c  |0 
 arch/{i386 = x86}/boot/version.c  |0 
 arch/{i386 = x86}/boot/vesa.h |0 
 arch/{i386 = x86}/boot/video-bios.c   |0 
 arch/{i386 = x86}/boot/video-vesa.c   |0 
 arch/{i386 = x86}/boot/video-vga.c|0 
 arch/{i386 = x86}/boot/video.c|0 
 arch/{i386 = x86}/boot/video.h|0 
 arch/{i386 = x86}/boot/voyager.c  |0 
 arch/x86/crypto/Makefile   |5 +
 .../crypto/Makefile = x86/crypto/Makefile_32} |4 +-
 .../crypto/Makefile = x86/crypto/Makefile_64} |4 +-
 arch/{i386 = x86}/crypto/aes-i586-asm.S   |0 
 arch/{x86_64 = x86}/crypto/aes-x86_64-asm.S   |0 
 arch/{i386/crypto/aes.c = x86/crypto/aes_32.c}|0 
 arch/{x86_64/crypto/aes.c = x86/crypto/aes_64.c}  |0 
 arch/{i386 = x86}/crypto/twofish-i586-asm.S   |0 
 arch/{x86_64 = x86}/crypto/twofish-x86_64-asm.S   |0 
 .../crypto/twofish.c = x86/crypto/twofish_32.c}   |0 
 .../crypto/twofish.c = x86/crypto/twofish_64.c}   |0 
 arch/{i386/defconfig = x86/defconfig_32}  |0 
 arch/{x86_64/defconfig = x86/defconfig_64}|0 
 arch/{x86_64 = x86}/ia32/Makefile |0

Re: [RFC, Announce] Unified x86 architecture, arch/x86



> On Saturday 21 July 2007 01:55, Michal Piotrowski wrote:
> >
> > I really like this idea - code duplication is a bad thing.
>
> Did you actually look at the patch? It doesn't have a single line
> less duplication than there was before. Everything that could
> be easily shared was shared already.
>
> It's just new window dressing without any real advantages.

And did you read what tglx wrote?

This patch was the beginning of the merger, not the end result. It strived
for binary identical images. It was to put everything together as a
_starting_point_!   The next thing to do after this is to start the
merging.

-- Steve

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Saturday 21 July 2007 01:55, Michal Piotrowski wrote:
> Hi,
>
> On 21/07/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > We are pleased to announce a project we've been working on for some
> > time: the unified x86 architecture tree, or "arch/x86" - and we'd like
> > to solicit feedback about it.
> >
> > What is this about?
>
> [..]
>
> > As usual, comments and suggestions are welcome!
>
> I really like this idea - code duplication is a bad thing.

Did you actually look at the patch? It doesn't have a single line
less duplication than there was before. Everything that could
be easily shared was shared already. 

It's just new window dressing without any real advantages.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Saturday 21 July 2007 00:32, Thomas Gleixner wrote:
> We are pleased to announce a project we've been working on for some
> time: the unified x86 architecture tree, or "arch/x86" - and we'd like
> to solicit feedback about it.

Well you know my position on this. I think it's a bad idea because
it means we can never get rid of any old junk. IMNSHO arch/x86_64
is significantly cleaner and simpler in many ways than arch/i386 and I would
like to preserve that. Also in general arch/x86_64 is much easier to hack
than arch/i386 because it's easier to regression test and in general
has to care about much less junk. And I don't 
know of any way to ever fix that for i386 besides splitting the old
stuff off completely.

Besides radical file movements like this are bad anyways. They cause
a big break in patchkits and forward/backwards porting that doesn't 
really help anybody.

> This causes double maintenance
> even for functionality that is conceptually the same for the 32-bit and
> the 64-bit tree. (such as support for standard PC platform architecture
> devices)

It's not really the same platform: one is PC hardware going back forever
with zillions of bugs, the other is modern PC platforms which much less
bugs and quirks

To see it otherwise it's more a junkification of arch/x86_64 than
a cleanup of arch/i386 -- in fact you didn't really clean up arch/i386 
at all.

> How did we do it?
> -
>
> As an initial matter, we made it painstakingly sure that the resulting
> .o files in a 32-bit build are bit for bit equal.

You got not a single line less code duplication then, so i don't really
see the point of this.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Yinghai Lu

On 7/20/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:

* Jeff Garzik <[EMAIL PROTECTED]> wrote:

> I agree with Andi...  it's quite nice to be able to leave some
> arch/i386 stuff, and not carry it over to arch/x86-64.

we can leave those few items in arch/x86 just as much. No need to keep
around a legacy tree for that.

how about making all files ans directories take _32 or _64 in the name?
except the files or dir that are shared.

for example: k8_bus.c is only need by 64 ===> change it to k8_bus_64.c
mach-generic===> mach-generic_32

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Glauber de Oliveira Costa

On 7/20/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:

> I really like the idea of a unified source tree for the 2 x86 variants.
> The technical differences are really small (of course there are
> differences, especially in the boot sequence), and striving to unify as
> much as possible while having a clean way to do per 32/64 bit parts as
> well is something that imo is the right thing.
>

Not to mention all the paravirt stuff that's going on. Having a single
x86 arch to work with would be greatly beneficial to the work being done
to port paravirt to x86_64.

As for paravirt, it'd really help. As I had the tree lagged behind by
so much, a great part of the work now is checking where i386 is,
seeing if it applies for 64-bit, and so on. The differences are not so
huge, and I'm trying my best to not let them deviate too much. It
could mostly be built incrementally.

And I bet a huge part of the tree could be like this too: In most
places, they are different for no particular reason, just because two
people implemented it separately. There'd be a huge effort to bring
those differences into an end, but I think I'd pay in future
development speed. (not to mention the duplicate bugs linus have
already talked about)

Way to go, Thomas and Ingo!

I am pretty much for it too.

--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Sat, 21 Jul 2007, Arnd Bergmann wrote:

> On Saturday 21 July 2007, Thomas Gleixner wrote:

>
> In my experience, it's very helpful to have a single set of header
> files, and merging the two versions of one header usually exposes
> bugs that have been fixed in only one of the two, so you get
> to fix actual bugs in the process.

This can still be done after the merge tglx did.

>
> In the s390 merge, I also started out in an attempt to guarantee
> unchanged object files, much like what you describe. However, it
> turned out that fixing it in the process is actually easier.
> Either way, 'diff -D __x86_64__' is a great tool for a start, you
> should try it out to see how easy it is to merge a lot of files.
>
> To put it into perspective, I think the s390 merge was a lot easier
> than the x86 merge, because there is only a very limited set of
> hardware configurations for s390 compared to others. We ended up
> doing the full merge with three people within less than a week
> and no separate files at all.

This is the big reason they wanted to keep it binary identical. Since
there are just way too many different configs out there in the x86
world

>
> OTOH, the powerpc merge is now going into its third year, mostly
> because it was started with the intention to remove all cruft
> in the process and to only allow sane code into the new architecture.

I'd expect x86 to move much faster, just because there are more developers
and users of x86 PCs than there are for powerpc.

>
> The steps that I'd suggest instead are:
>
> * merge all exported header files of the two architectures. This
>   alone is a worthy goal, because it allows us to get rid of
>   the ugly code for deciding which version to use in installed
>   headers and elsewhere.

I don't see why this can't be done after the first "Big" merge.

>
> * Create an arch/x86/Makefile that descends into ../i386/* and
>   ../x86_64/* instead of its subdirectories.

The thing that Thomas pointed out, is that physical location of the source
actually does matter. Having two files side by side with the same name
except for a _32.c and _64.c, makes a developer want to merge them.

A perfect example is looking at both
  arch/x86/kernel/module_{32,64}.c
One would be encouraged to make that into a single file. But having
a arch/i386/kernel/module.c and a arch/x86_64/kernel/module.c would
take some time before anyone would care.

>
> * Merge the arch/x86/* subdirectories, one at a time, starting with
>   the low-hanging fruit like oprofile or pci, and do the hard
>   ones like mm and kernel last.

Your looking at a 10year plus merge with that approach. I think that is
exactly what Ingo and Thomas _dont_ want.  Doing it as the big bang way as
is posted in this patch is the fastest way to get where we want to go.

>
> Unfortunately, I don't think I'll spend much time on this, so I
> don't get to decide on it, but you asked for feedback ;-)
>

I'm actually looking forward to helping out here ;-)

-- Steve

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Gabriel C

Thomas Gleixner wrote:
>

[...]

> As usual, comments and suggestions are welcome!


Compiles and boots fine here ( on my Dell Precision WorkStation 530 MT ). And 
nothing broke so far.

I only got some Kconfig warnings[1] with my config[2] but that is.

( I don't know whatever this matter but it boots 7,52 seconds faster as current 
git head )

[1]http://194.231.229.228/linux-x86/warning
[2]http://194.231.229.228/linux-x86/config-x86

> 
>   Thomas, Ingo
> 
> 


Regards,

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Arnd Bergmann

On Saturday 21 July 2007, Thomas Gleixner wrote:
> The topic of sharing more x86 code has been discussed on LKML a number 
> of times. Various approaches were discussed and we decided to advance 
> the discussion by implementing a full solution that brings the 
> transition to a shared tree to completion.

Great stuff. I've worked on doing the same for s390 and powerpc
in the past, and really think it's the right thing to do. I've
even started my own x86 merge two or three times in the past
but never got very far because of the quickly moving source.

> In this initial implementation the old arch/i386 and arch/x86_64 trees 
> are removed _immediately_, in the same commit, and all future x86 
> development goes on in the new, shared tree. So the transition right now 
> is one atomic operation.
> 
> As a next step we plan to generate a gradual, fully bisectable, fully
> working switchover from the current code to the fully populated
> arch/x86 tree. It will result in about 1000-2000 commits. We are
> releasing our current solution because it 100% represents the finally
> resulting arch/x86 source tree already, and we first wanted to make
> sure that the new architecture layout works fine and folks are happy
> before we go and do the (even more complex) fine-grained work.

I don't think it's really good to do it this way, or maybe I'm still
misunderstanding where you're going. If you really want to end
up with the exact set of files that you have your tree now, I see
absolutely zero point in making it bisectable. On the contrary,
there is nothing particularly complicated in it, so once it has
seen some amount of testing it can better get merged in one
big changeset. I'm just not convinced that it actully is what
we want to end up with.

In my experience, it's very helpful to have a single set of header
files, and merging the two versions of one header usually exposes
bugs that have been fixed in only one of the two, so you get
to fix actual bugs in the process.

In the s390 merge, I also started out in an attempt to guarantee
unchanged object files, much like what you describe. However, it
turned out that fixing it in the process is actually easier.
Either way, 'diff -D __x86_64__' is a great tool for a start, you
should try it out to see how easy it is to merge a lot of files.

To put it into perspective, I think the s390 merge was a lot easier
than the x86 merge, because there is only a very limited set of
hardware configurations for s390 compared to others. We ended up
doing the full merge with three people within less than a week
and no separate files at all.

OTOH, the powerpc merge is now going into its third year, mostly
because it was started with the intention to remove all cruft
in the process and to only allow sane code into the new architecture.

The steps that I'd suggest instead are:

* merge all exported header files of the two architectures. This
  alone is a worthy goal, because it allows us to get rid of
  the ugly code for deciding which version to use in installed
  headers and elsewhere.

* Merge the remaining header files, to end up with a single
  include/asm-x86 directory.

* Come up with a model that integrates the machine type selection
  of i386 with the way we build things on x86_64. One way would
  be to make X86_64 another platform next to X86_PC, X86_VOYAGER
  and the others.

* Create an arch/x86/Kconfig that handles the new common
  configuration

* Create an arch/x86/Makefile that descends into ../i386/* and
  ../x86_64/* instead of its subdirectories.

* Merge the arch/x86/* subdirectories, one at a time, starting with
  the low-hanging fruit like oprofile or pci, and do the hard
  ones like mm and kernel last.

Unfortunately, I don't think I'll spend much time on this, so I
don't get to decide on it, but you asked for feedback ;-)

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


On 21/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:


* Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> >We are pleased to announce a project we've been working on for some
> >time: the unified x86 architecture tree, or "arch/x86" - and we'd
> >like to solicit feedback about it.
> >
> >What is this about?
> [..]
> >As usual, comments and suggestions are welcome!
>
> I really like this idea - code duplication is a bad thing.
>
> BTW. I don't see any regression here :)

cool - could you tell us a bit more about on what type of box you tried
it,


it is an old P4 (i386)


and how wide and versatile the .config is?


http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-git15/config



Ingo



Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread H. Peter Anvin

Alan Cox wrote:
> On Fri, 20 Jul 2007 18:38:39 -0400
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> 
>> I agree with Andi...  it's quite nice to be able to leave some arch/i386 
>> stuff, and not carry it over to arch/x86-64.
> 
> Its easy enough to push that stuff into arch/x86/legacy and have one
> subdirectory of stuff to pull in for ancient systems.

The other thing is that "legacy" in this context is fungible.  No IOMMU
was legacy until the Intel x86-64 chips came out, and I can promise you
that some legacy code will be necessary once we start seeing VIA and
others come out with embedded x86-64.

On the other hand, it's pretty bloody safe to assume that we'll never
see an x86-64 chip without CPUID, CMOV, FXSAVE, SSE-2, CMPXCHG, etc.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


* Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> >We are pleased to announce a project we've been working on for some 
> >time: the unified x86 architecture tree, or "arch/x86" - and we'd 
> >like to solicit feedback about it.
> >
> >What is this about?
> [..]
> >As usual, comments and suggestions are welcome!
> 
> I really like this idea - code duplication is a bad thing.
> 
> BTW. I don't see any regression here :)

cool - could you tell us a bit more about on what type of box you tried 
it, and how wide and versatile the .config is?

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


Hi,

On 21/07/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:

We are pleased to announce a project we've been working on for some
time: the unified x86 architecture tree, or "arch/x86" - and we'd like
to solicit feedback about it.

What is this about?

[..]

As usual, comments and suggestions are welcome!


I really like this idea - code duplication is a bad thing.

BTW. I don't see any regression here :)



Thomas, Ingo


Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Alan Cox

On Fri, 20 Jul 2007 18:38:39 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:

> I agree with Andi...  it's quite nice to be able to leave some arch/i386 
> stuff, and not carry it over to arch/x86-64.

Its easy enough to push that stuff into arch/x86/legacy and have one
subdirectory of stuff to pull in for ancient systems.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


On Fri, 20 Jul 2007, Arjan van de Ven wrote:

> On Sat, 2007-07-21 at 00:32 +0200, Thomas Gleixner wrote:
> > We are pleased to announce a project we've been working on for some
> > time: the unified x86 architecture tree, or "arch/x86" - and we'd like
> > to solicit feedback about it.
>
>
>
> I really like the idea of a unified source tree for the 2 x86 variants.
> The technical differences are really small (of course there are
> differences, especially in the boot sequence), and striving to unify as
> much as possible while having a clean way to do per 32/64 bit parts as
> well is something that imo is the right thing.
>

Not to mention all the paravirt stuff that's going on. Having a single
x86 arch to work with would be greatly beneficial to the work being done
to port paravirt to x86_64.

Way to go, Thomas and Ingo!

-- Steve

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Arjan van de Ven

On Sat, 2007-07-21 at 00:32 +0200, Thomas Gleixner wrote:
> We are pleased to announce a project we've been working on for some 
> time: the unified x86 architecture tree, or "arch/x86" - and we'd like 
> to solicit feedback about it.

I really like the idea of a unified source tree for the 2 x86 variants.
The technical differences are really small (of course there are
differences, especially in the boot sequence), and striving to unify as
much as possible while having a clean way to do per 32/64 bit parts as
well is something that imo is the right thing.

I'm more than happy to help with this effort, and have people in my
group at Intel help test and engineer this as well.

The technical approach of first moving (in an automated way) everything
into one directory, and then merge pieces one by one is appealing since
it can be done incrementally and carefully, while testing the "can we do
separate bits" from the start.

So in short, way to go, I hope we can get this thing done as soon as
possible. Heck it looks like the infrastructure (not the unification)
can make it into 2.6.23 merge window still, so that the entire 2.6.23
window can be used to develop merged-functionality pieces...

Greetings,
Arjan van de Ven

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Linus Torvalds

On Fri, 20 Jul 2007, Jeff Garzik wrote:

> Ingo Molnar wrote:
> > * Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > 
> > > I agree with Andi...  it's quite nice to be able to leave some arch/i386
> > > stuff, and not carry it over to arch/x86-64.
> > 
> > we can leave those few items in arch/x86 just as much. No need to keep
> > around a legacy tree for that.
> 
> By extension it makes doing that sort of thing, in general, more difficult.
> Which is IMO not desirable.

I think it's *much* harder to carry legacy things around in an old tree 
that almost nobody even uses any more (probably not true yet, but for most 
of the main developers, I bet it will be true in a year). Especially one 
that just duplicates 99% of the stuff.

There really isn't that much legacy crud. There are things like random 
quirks, but every time I hear the (theoretical) argument about how much 
time and effort we save by having it duplicated somewhere else, I think 
about all the time we definitely waste by fixing the same bug twice (and 
worry about the cases where we don't).

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


Ingo Molnar wrote:

* Jeff Garzik <[EMAIL PROTECTED]> wrote:

I agree with Andi...  it's quite nice to be able to leave some 
arch/i386 stuff, and not carry it over to arch/x86-64.


we can leave those few items in arch/x86 just as much. No need to keep 
around a legacy tree for that.


By extension it makes doing that sort of thing, in general, more 
difficult.  Which is IMO not desirable.


Jeff



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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


* Jeff Garzik <[EMAIL PROTECTED]> wrote:

> I agree with Andi...  it's quite nice to be able to leave some 
> arch/i386 stuff, and not carry it over to arch/x86-64.

we can leave those few items in arch/x86 just as much. No need to keep 
around a legacy tree for that.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

I agree with Andi...  it's quite nice to be able to leave some arch/i386 
stuff, and not carry it over to arch/x86-64.


Jeff



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

[RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Thomas Gleixner

We are pleased to announce a project we've been working on for some
time: the unified x86 architecture tree, or "arch/x86" - and we'd like
to solicit feedback about it.

What is this about?
---

The topic of sharing more x86 code has been discussed on LKML a number
of times. Various approaches were discussed and we decided to advance
the discussion by implementing a full solution that brings the
transition to a shared tree to completion.

Warning: our approach is quite a bit more extreme than what has been
suggested before.

The core idea behind our project is simple to describe: we introduce a
new arch/x86/ and include/asm-x86/ file hierarchy that includes all the
existing 32-bit and 64-bit x86 code and allows the building of either a
32-bit (i386) kernel or a 64-bit (x86_64) kernel.

In this initial implementation the old arch/i386 and arch/x86_64 trees
are removed _immediately_, in the same commit, and all future x86
development goes on in the new, shared tree. So the transition right now
is one atomic operation.

As a next step we plan to generate a gradual, fully bisectable, fully
working switchover from the current code to the fully populated
arch/x86 tree. It will result in about 1000-2000 commits. We are
releasing our current solution because it 100% represents the finally
resulting arch/x86 source tree already, and we first wanted to make
sure that the new architecture layout works fine and folks are happy
before we go and do the (even more complex) fine-grained work.

A git tree is available from:

git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git

One (large!) combo patch is available at:

http://kernel.org/pub/linux/kernel/people/tglx/linux-x86.2.6.22-git-ede13d.combo.patch.bz2

the patch is against this upstream -git head:

commit ede13d81b4dda409a6d271b34b8e2ec9383e255d

It makes little sense to apply this patch to anything else because
these architectures are such a fast-moving target.

Why do we want to do this?
--

We believe that the whole x86 CPU family is very much related and should
be supported in a single architecture tree. All 64-bit CPUs implement
the ability to execute pure 32-bit kernels, and will probably do so for
the next couple of decades. So it's not like it will ever be possible to
get rid of our legacies: for example even the latest 64-bit CPUs
implement the legacy "A20 line" feature that was already a weird
outdated hack in the days of 16-bit x8086 CPUs.

So what can we do? We should learn to live better with our legacies, and
we should avoid reinventing the wheel in 64-bit code. Today there's
already some limited code sharing between the i386 and x86_64 trees, but
it's quite non-obvious: it's either done via a placeholder file that
#include's an out-of-arch file, or a Makefile rule that uses an
out-of-arch file. These 'cross-tree' file uses are not visible at the
target point, and people sometimes break "the other arch" if they modify
the file, because they are not aware of there being code sharing.

Furthermore, the separate i386 and x86_64 trees often cause kernel
writers to (unconsciously) think in either 32-bit or in 64-bit terms,
instead of thinking about the two things in one way. It also happened
numerous times that code that was originally copied from arch/i386 gets
64-bit-only additions in arch/x86_64, and if a bug is fixed in the
32-bit code, that fix is not applied to the x86_64 tree. Or some
function is cleaned up and improved in the x86_64 tree, but that
improvement is not easily adaptable to arch/i386, because the x86_64
code became 64-bit only already.

All in one: the two architecture trees are "way too far apart" from each
other, which causes the source code to diverge not only physically but
structurally as well. The whole setup works _against_ sharing code,
instead of working _for_ sharing code. This causes double maintenance
even for functionality that is conceptually the same for the 32-bit and
the 64-bit tree. (such as support for standard PC platform architecture
devices)

How did we do it?
-

As an initial matter, we made it painstakingly sure that the resulting
.o files in a 32-bit build are bit for bit equal. (at least in terms of
.text, small .data differences are there due to the namespace changes).
We also made it sure that you can pick up _any_ existing 32-bit .config,
stick it into our new arch/x86 tree and build a fully working 32-bit
kernel. Same is the goal for any existing 64-bit .config as well.

The shared x86 tree is _not_ "merge the 32-bit legacy code into the
x86_64 tree". It is _not_ "create a x86_64 tree that can run on modern
32-bit hardware too, leave arch/i386 around for ancient stuff". It is a
unification between equals, all legacies and all new code is unified
into one shared tree. Nothing is left behind.

A key component of our change is that only a very small portion of the
conversion was

[RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Thomas Gleixner

We are pleased to announce a project we've been working on for some
time: the unified x86 architecture tree, or arch/x86 - and we'd like
to solicit feedback about it.

What is this about?
---

Warning: our approach is quite a bit more extreme than what has been
suggested before.

A git tree is available from:

git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git

One (large!) combo patch is available at:

http://kernel.org/pub/linux/kernel/people/tglx/linux-x86.2.6.22-git-ede13d.combo.patch.bz2

the patch is against this upstream -git head:

commit ede13d81b4dda409a6d271b34b8e2ec9383e255d

It makes little sense to apply this patch to anything else because
these architectures are such a fast-moving target.

Why do we want to do this?
--

We believe that the whole x86 CPU family is very much related and should
be supported in a single architecture tree. All 64-bit CPUs implement
the ability to execute pure 32-bit kernels, and will probably do so for
the next couple of decades. So it's not like it will ever be possible to
get rid of our legacies: for example even the latest 64-bit CPUs
implement the legacy A20 line feature that was already a weird
outdated hack in the days of 16-bit x8086 CPUs.

So what can we do? We should learn to live better with our legacies, and
we should avoid reinventing the wheel in 64-bit code. Today there's
already some limited code sharing between the i386 and x86_64 trees, but
it's quite non-obvious: it's either done via a placeholder file that
#include's an out-of-arch file, or a Makefile rule that uses an
out-of-arch file. These 'cross-tree' file uses are not visible at the
target point, and people sometimes break the other arch if they modify
the file, because they are not aware of there being code sharing.

All in one: the two architecture trees are way too far apart from each
other, which causes the source code to diverge not only physically but
structurally as well. The whole setup works _against_ sharing code,
instead of working _for_ sharing code. This causes double maintenance
even for functionality that is conceptually the same for the 32-bit and
the 64-bit tree. (such as support for standard PC platform architecture
devices)

How did we do it?
-

The shared x86 tree is _not_ merge the 32-bit legacy code into the
x86_64 tree. It is _not_ create a x86_64 tree that can run on modern
32-bit hardware too, leave arch/i386 around for ancient stuff. It is a
unification between equals, all legacies and all new code is unified
into one shared tree. Nothing is left behind.

A key component of our change is that only a very small portion of the
conversion was done

Re: [RFC, Announce] Unified x86 architecture, arch/x86

I agree with Andi...  it's quite nice to be able to leave some arch/i386 
stuff, and not carry it over to arch/x86-64.


Jeff



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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


* Jeff Garzik [EMAIL PROTECTED] wrote:

 I agree with Andi...  it's quite nice to be able to leave some 
 arch/i386 stuff, and not carry it over to arch/x86-64.

we can leave those few items in arch/x86 just as much. No need to keep 
around a legacy tree for that.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


Ingo Molnar wrote:

* Jeff Garzik [EMAIL PROTECTED] wrote:

I agree with Andi...  it's quite nice to be able to leave some 
arch/i386 stuff, and not carry it over to arch/x86-64.


we can leave those few items in arch/x86 just as much. No need to keep 
around a legacy tree for that.


By extension it makes doing that sort of thing, in general, more 
difficult.  Which is IMO not desirable.


Jeff



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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Linus Torvalds



On Fri, 20 Jul 2007, Jeff Garzik wrote:

 Ingo Molnar wrote:
  * Jeff Garzik [EMAIL PROTECTED] wrote:
  
   I agree with Andi...  it's quite nice to be able to leave some arch/i386
   stuff, and not carry it over to arch/x86-64.
  
  we can leave those few items in arch/x86 just as much. No need to keep
  around a legacy tree for that.
 
 By extension it makes doing that sort of thing, in general, more difficult.
 Which is IMO not desirable.

I think it's *much* harder to carry legacy things around in an old tree 
that almost nobody even uses any more (probably not true yet, but for most 
of the main developers, I bet it will be true in a year). Especially one 
that just duplicates 99% of the stuff.

There really isn't that much legacy crud. There are things like random 
quirks, but every time I hear the (theoretical) argument about how much 
time and effort we save by having it duplicated somewhere else, I think 
about all the time we definitely waste by fixing the same bug twice (and 
worry about the cases where we don't).

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Arjan van de Ven

On Sat, 2007-07-21 at 00:32 +0200, Thomas Gleixner wrote:
 We are pleased to announce a project we've been working on for some 
 time: the unified x86 architecture tree, or arch/x86 - and we'd like 
 to solicit feedback about it.



I really like the idea of a unified source tree for the 2 x86 variants.
The technical differences are really small (of course there are
differences, especially in the boot sequence), and striving to unify as
much as possible while having a clean way to do per 32/64 bit parts as
well is something that imo is the right thing.

I'm more than happy to help with this effort, and have people in my
group at Intel help test and engineer this as well.

The technical approach of first moving (in an automated way) everything
into one directory, and then merge pieces one by one is appealing since
it can be done incrementally and carefully, while testing the can we do
separate bits from the start.

So in short, way to go, I hope we can get this thing done as soon as
possible. Heck it looks like the infrastructure (not the unification)
can make it into 2.6.23 merge window still, so that the entire 2.6.23
window can be used to develop merged-functionality pieces...

Greetings,
Arjan van de Ven


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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


On Fri, 20 Jul 2007, Arjan van de Ven wrote:

 On Sat, 2007-07-21 at 00:32 +0200, Thomas Gleixner wrote:
  We are pleased to announce a project we've been working on for some
  time: the unified x86 architecture tree, or arch/x86 - and we'd like
  to solicit feedback about it.



 I really like the idea of a unified source tree for the 2 x86 variants.
 The technical differences are really small (of course there are
 differences, especially in the boot sequence), and striving to unify as
 much as possible while having a clean way to do per 32/64 bit parts as
 well is something that imo is the right thing.


Not to mention all the paravirt stuff that's going on. Having a single
x86 arch to work with would be greatly beneficial to the work being done
to port paravirt to x86_64.

Way to go, Thomas and Ingo!

-- Steve

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Alan Cox

On Fri, 20 Jul 2007 18:38:39 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:

 I agree with Andi...  it's quite nice to be able to leave some arch/i386 
 stuff, and not carry it over to arch/x86-64.

Its easy enough to push that stuff into arch/x86/legacy and have one
subdirectory of stuff to pull in for ancient systems.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


Hi,

On 21/07/07, Thomas Gleixner [EMAIL PROTECTED] wrote:

We are pleased to announce a project we've been working on for some
time: the unified x86 architecture tree, or arch/x86 - and we'd like
to solicit feedback about it.

What is this about?

[..]

As usual, comments and suggestions are welcome!


I really like this idea - code duplication is a bad thing.

BTW. I don't see any regression here :)



Thomas, Ingo


Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC, Announce] Unified x86 architecture, arch/x86


* Michal Piotrowski [EMAIL PROTECTED] wrote:

 We are pleased to announce a project we've been working on for some 
 time: the unified x86 architecture tree, or arch/x86 - and we'd 
 like to solicit feedback about it.
 
 What is this about?
 [..]
 As usual, comments and suggestions are welcome!
 
 I really like this idea - code duplication is a bad thing.
 
 BTW. I don't see any regression here :)

cool - could you tell us a bit more about on what type of box you tried 
it, and how wide and versatile the .config is?

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread H. Peter Anvin

Alan Cox wrote:
 On Fri, 20 Jul 2007 18:38:39 -0400
 Jeff Garzik [EMAIL PROTECTED] wrote:
 
 I agree with Andi...  it's quite nice to be able to leave some arch/i386 
 stuff, and not carry it over to arch/x86-64.
 
 Its easy enough to push that stuff into arch/x86/legacy and have one
 subdirectory of stuff to pull in for ancient systems.

The other thing is that legacy in this context is fungible.  No IOMMU
was legacy until the Intel x86-64 chips came out, and I can promise you
that some legacy code will be necessary once we start seeing VIA and
others come out with embedded x86-64.

On the other hand, it's pretty bloody safe to assume that we'll never
see an x86-64 chip without CPUID, CMOV, FXSAVE, SSE-2, CMPXCHG, etc.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86


On 21/07/07, Ingo Molnar [EMAIL PROTECTED] wrote:


* Michal Piotrowski [EMAIL PROTECTED] wrote:

 We are pleased to announce a project we've been working on for some
 time: the unified x86 architecture tree, or arch/x86 - and we'd
 like to solicit feedback about it.
 
 What is this about?
 [..]
 As usual, comments and suggestions are welcome!

 I really like this idea - code duplication is a bad thing.

 BTW. I don't see any regression here :)

cool - could you tell us a bit more about on what type of box you tried
it,


it is an old P4 (i386)


and how wide and versatile the .config is?


http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-git15/config



Ingo



Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Arnd Bergmann

On Saturday 21 July 2007, Thomas Gleixner wrote:
 The topic of sharing more x86 code has been discussed on LKML a number 
 of times. Various approaches were discussed and we decided to advance 
 the discussion by implementing a full solution that brings the 
 transition to a shared tree to completion.

Great stuff. I've worked on doing the same for s390 and powerpc
in the past, and really think it's the right thing to do. I've
even started my own x86 merge two or three times in the past
but never got very far because of the quickly moving source.

 In this initial implementation the old arch/i386 and arch/x86_64 trees 
 are removed _immediately_, in the same commit, and all future x86 
 development goes on in the new, shared tree. So the transition right now 
 is one atomic operation.
 
 As a next step we plan to generate a gradual, fully bisectable, fully
 working switchover from the current code to the fully populated
 arch/x86 tree. It will result in about 1000-2000 commits. We are
 releasing our current solution because it 100% represents the finally
 resulting arch/x86 source tree already, and we first wanted to make
 sure that the new architecture layout works fine and folks are happy
 before we go and do the (even more complex) fine-grained work.

I don't think it's really good to do it this way, or maybe I'm still
misunderstanding where you're going. If you really want to end
up with the exact set of files that you have your tree now, I see
absolutely zero point in making it bisectable. On the contrary,
there is nothing particularly complicated in it, so once it has
seen some amount of testing it can better get merged in one
big changeset. I'm just not convinced that it actully is what
we want to end up with.

In my experience, it's very helpful to have a single set of header
files, and merging the two versions of one header usually exposes
bugs that have been fixed in only one of the two, so you get
to fix actual bugs in the process.

In the s390 merge, I also started out in an attempt to guarantee
unchanged object files, much like what you describe. However, it
turned out that fixing it in the process is actually easier.
Either way, 'diff -D __x86_64__' is a great tool for a start, you
should try it out to see how easy it is to merge a lot of files.

To put it into perspective, I think the s390 merge was a lot easier
than the x86 merge, because there is only a very limited set of
hardware configurations for s390 compared to others. We ended up
doing the full merge with three people within less than a week
and no separate files at all.

OTOH, the powerpc merge is now going into its third year, mostly
because it was started with the intention to remove all cruft
in the process and to only allow sane code into the new architecture.

The steps that I'd suggest instead are:

* merge all exported header files of the two architectures. This
  alone is a worthy goal, because it allows us to get rid of
  the ugly code for deciding which version to use in installed
  headers and elsewhere.

* Merge the remaining header files, to end up with a single
  include/asm-x86 directory.

* Come up with a model that integrates the machine type selection
  of i386 with the way we build things on x86_64. One way would
  be to make X86_64 another platform next to X86_PC, X86_VOYAGER
  and the others.

* Create an arch/x86/Kconfig that handles the new common
  configuration

* Create an arch/x86/Makefile that descends into ../i386/* and
  ../x86_64/* instead of its subdirectories.

* Merge the arch/x86/* subdirectories, one at a time, starting with
  the low-hanging fruit like oprofile or pci, and do the hard
  ones like mm and kernel last.

Unfortunately, I don't think I'll spend much time on this, so I
don't get to decide on it, but you asked for feedback ;-)

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Gabriel C

Thomas Gleixner wrote:


[...]

 As usual, comments and suggestions are welcome!


Compiles and boots fine here ( on my Dell Precision WorkStation 530 MT ). And 
nothing broke so far.

I only got some Kconfig warnings[1] with my config[2] but that is.

( I don't know whatever this matter but it boots 7,52 seconds faster as current 
git head )

[1]http://194.231.229.228/linux-x86/warning
[2]http://194.231.229.228/linux-x86/config-x86

 
   Thomas, Ingo
 
 


Regards,

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Sat, 21 Jul 2007, Arnd Bergmann wrote:

 On Saturday 21 July 2007, Thomas Gleixner wrote:


 In my experience, it's very helpful to have a single set of header
 files, and merging the two versions of one header usually exposes
 bugs that have been fixed in only one of the two, so you get
 to fix actual bugs in the process.

This can still be done after the merge tglx did.


 In the s390 merge, I also started out in an attempt to guarantee
 unchanged object files, much like what you describe. However, it
 turned out that fixing it in the process is actually easier.
 Either way, 'diff -D __x86_64__' is a great tool for a start, you
 should try it out to see how easy it is to merge a lot of files.

 To put it into perspective, I think the s390 merge was a lot easier
 than the x86 merge, because there is only a very limited set of
 hardware configurations for s390 compared to others. We ended up
 doing the full merge with three people within less than a week
 and no separate files at all.

This is the big reason they wanted to keep it binary identical. Since
there are just way too many different configs out there in the x86
world


 OTOH, the powerpc merge is now going into its third year, mostly
 because it was started with the intention to remove all cruft
 in the process and to only allow sane code into the new architecture.

I'd expect x86 to move much faster, just because there are more developers
and users of x86 PCs than there are for powerpc.


 The steps that I'd suggest instead are:

 * merge all exported header files of the two architectures. This
   alone is a worthy goal, because it allows us to get rid of
   the ugly code for deciding which version to use in installed
   headers and elsewhere.

I don't see why this can't be done after the first Big merge.


 * Create an arch/x86/Makefile that descends into ../i386/* and
   ../x86_64/* instead of its subdirectories.

The thing that Thomas pointed out, is that physical location of the source
actually does matter. Having two files side by side with the same name
except for a _32.c and _64.c, makes a developer want to merge them.

A perfect example is looking at both
  arch/x86/kernel/module_{32,64}.c
One would be encouraged to make that into a single file. But having
a arch/i386/kernel/module.c and a arch/x86_64/kernel/module.c would
take some time before anyone would care.


 * Merge the arch/x86/* subdirectories, one at a time, starting with
   the low-hanging fruit like oprofile or pci, and do the hard
   ones like mm and kernel last.

Your looking at a 10year plus merge with that approach. I think that is
exactly what Ingo and Thomas _dont_ want.  Doing it as the big bang way as
is posted in this patch is the fastest way to get where we want to go.


 Unfortunately, I don't think I'll spend much time on this, so I
 don't get to decide on it, but you asked for feedback ;-)


I'm actually looking forward to helping out here ;-)

-- Steve

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Glauber de Oliveira Costa


On 7/20/07, Steven Rostedt [EMAIL PROTECTED] wrote:


 I really like the idea of a unified source tree for the 2 x86 variants.
 The technical differences are really small (of course there are
 differences, especially in the boot sequence), and striving to unify as
 much as possible while having a clean way to do per 32/64 bit parts as
 well is something that imo is the right thing.


Not to mention all the paravirt stuff that's going on. Having a single
x86 arch to work with would be greatly beneficial to the work being done
to port paravirt to x86_64.


As for paravirt, it'd really help. As I had the tree lagged behind by
so much, a great part of the work now is checking where i386 is,
seeing if it applies for 64-bit, and so on. The differences are not so
huge, and I'm trying my best to not let them deviate too much. It
could mostly be built incrementally.

And I bet a huge part of the tree could be like this too: In most
places, they are different for no particular reason, just because two
people implemented it separately. There'd be a huge effort to bring
those differences into an end, but I think I'd pay in future
development speed. (not to mention the duplicate bugs linus have
already talked about)


Way to go, Thomas and Ingo!

I am pretty much for it too.


--
Glauber de Oliveira Costa.
Free as in Freedom
http://glommer.net

The less confident you are, the more serious you have to act.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC, Announce] Unified x86 architecture, arch/x86

2007-07-20 Thread Yinghai Lu


On 7/20/07, Ingo Molnar [EMAIL PROTECTED] wrote:


* Jeff Garzik [EMAIL PROTECTED] wrote:

 I agree with Andi...  it's quite nice to be able to leave some
 arch/i386 stuff, and not carry it over to arch/x86-64.

we can leave those few items in arch/x86 just as much. No need to keep
around a legacy tree for that.


how about making all files ans directories take _32 or _64 in the name?
except the files or dir that are shared.

for example: k8_bus.c is only need by 64 === change it to k8_bus_64.c
mach-generic=== mach-generic_32

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Saturday 21 July 2007 00:32, Thomas Gleixner wrote:
 We are pleased to announce a project we've been working on for some
 time: the unified x86 architecture tree, or arch/x86 - and we'd like
 to solicit feedback about it.

Well you know my position on this. I think it's a bad idea because
it means we can never get rid of any old junk. IMNSHO arch/x86_64
is significantly cleaner and simpler in many ways than arch/i386 and I would
like to preserve that. Also in general arch/x86_64 is much easier to hack
than arch/i386 because it's easier to regression test and in general
has to care about much less junk. And I don't 
know of any way to ever fix that for i386 besides splitting the old
stuff off completely.

Besides radical file movements like this are bad anyways. They cause
a big break in patchkits and forward/backwards porting that doesn't 
really help anybody.

 This causes double maintenance
 even for functionality that is conceptually the same for the 32-bit and
 the 64-bit tree. (such as support for standard PC platform architecture
 devices)

It's not really the same platform: one is PC hardware going back forever
with zillions of bugs, the other is modern PC platforms which much less
bugs and quirks

To see it otherwise it's more a junkification of arch/x86_64 than
a cleanup of arch/i386 -- in fact you didn't really clean up arch/i386 
at all.

 How did we do it?
 -

 As an initial matter, we made it painstakingly sure that the resulting
 .o files in a 32-bit build are bit for bit equal.

You got not a single line less code duplication then, so i don't really
see the point of this.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86

On Saturday 21 July 2007 01:55, Michal Piotrowski wrote:
 Hi,

 On 21/07/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
  We are pleased to announce a project we've been working on for some
  time: the unified x86 architecture tree, or arch/x86 - and we'd like
  to solicit feedback about it.
 
  What is this about?

 [..]

  As usual, comments and suggestions are welcome!

 I really like this idea - code duplication is a bad thing.

Did you actually look at the patch? It doesn't have a single line
less duplication than there was before. Everything that could
be easily shared was shared already. 

It's just new window dressing without any real advantages.

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

Re: [RFC, Announce] Unified x86 architecture, arch/x86