On Sat, 15 Sep 2007 20:36:23 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 15, 2007 at 02:32:58AM -0700, Andrew Morton wrote:
> > On Tue, 11 Sep 2007 23:14:22 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > People do not expect code under arch/i386/ to be used by code under
>
On Sat, Sep 15, 2007 at 02:32:58AM -0700, Andrew Morton wrote:
> On Tue, 11 Sep 2007 23:14:22 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > People do not expect code under arch/i386/ to be used by code under
> > arch/x86_64/ and vice versa.
>
> [OT: it drives me batshit that we ended up
On Wed, 12 Sep 2007 09:29:53 +0900 Paul Mundt <[EMAIL PROTECTED]> wrote:
> As I was the first one to do CONFIG_MMU=y/n in the same arch directory,
> since 2.5, I can tell you that that's simply crap. The only reason
> CONFIG_MMU=n gets broken all the time is because people don't think about
> it
On Tue, 11 Sep 2007 23:14:22 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
> People do not expect code under arch/i386/ to be used by code under
> arch/x86_64/ and vice versa.
[OT: it drives me batshit that we ended up including stuff in both directions]
-
To unsubscribe from this list: send the
On Tue, 11 Sep 2007 23:14:22 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:
People do not expect code under arch/i386/ to be used by code under
arch/x86_64/ and vice versa.
[OT: it drives me batshit that we ended up including stuff in both directions]
-
To unsubscribe from this list: send the
On Wed, 12 Sep 2007 09:29:53 +0900 Paul Mundt [EMAIL PROTECTED] wrote:
As I was the first one to do CONFIG_MMU=y/n in the same arch directory,
since 2.5, I can tell you that that's simply crap. The only reason
CONFIG_MMU=n gets broken all the time is because people don't think about
it in
On Sat, Sep 15, 2007 at 02:32:58AM -0700, Andrew Morton wrote:
On Tue, 11 Sep 2007 23:14:22 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:
People do not expect code under arch/i386/ to be used by code under
arch/x86_64/ and vice versa.
[OT: it drives me batshit that we ended up including
On Sat, 15 Sep 2007 20:36:23 +0200 Andi Kleen [EMAIL PROTECTED] wrote:
On Sat, Sep 15, 2007 at 02:32:58AM -0700, Andrew Morton wrote:
On Tue, 11 Sep 2007 23:14:22 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:
People do not expect code under arch/i386/ to be used by code under
>
> > If legacy.c numa.c, pcibios.c and visws.c placed in a directory named i386
> > then it would be obvious that this is i386 only.
>
> But none of it is "i386 only" and putting it in a directory of its own
> would be stupid and wrong. The visws.c thing is platform-specific thing,
> and the
On Sep 11 2007 14:51, Linus Torvalds wrote:
>On Tue, 11 Sep 2007, Andi Kleen wrote:
>>
>> Will that cause people to compile test both? I have my doubts that
>> will really work.
>
>If people don't compile-test both now, then why would they compile-test
>things when merged?
>
>So no, that's not
On Wed, Sep 12, 2007 at 10:27:16AM +0100, Christoph Hellwig wrote:
> On Tue, Sep 11, 2007 at 10:34:13PM +0200, Adrian Bunk wrote:
> > As an example, visws.c is as much non-64bit as it is pre-i686.
>
> Bullshit. visws were shipped with P3s.
Certainly true, but still not 64bit and never will be.
On Tue, Sep 11, 2007 at 10:34:13PM +0200, Adrian Bunk wrote:
> As an example, visws.c is as much non-64bit as it is pre-i686.
Bullshit. visws were shipped with P3s.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Sep 11 2007 14:51, Linus Torvalds wrote:
On Tue, 11 Sep 2007, Andi Kleen wrote:
Will that cause people to compile test both? I have my doubts that
will really work.
If people don't compile-test both now, then why would they compile-test
things when merged?
So no, that's not the point.
If legacy.c numa.c, pcibios.c and visws.c placed in a directory named i386
then it would be obvious that this is i386 only.
But none of it is i386 only and putting it in a directory of its own
would be stupid and wrong. The visws.c thing is platform-specific thing,
and the fact that
On Tue, Sep 11, 2007 at 10:34:13PM +0200, Adrian Bunk wrote:
As an example, visws.c is as much non-64bit as it is pre-i686.
Bullshit. visws were shipped with P3s.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Wed, Sep 12, 2007 at 10:27:16AM +0100, Christoph Hellwig wrote:
On Tue, Sep 11, 2007 at 10:34:13PM +0200, Adrian Bunk wrote:
As an example, visws.c is as much non-64bit as it is pre-i686.
Bullshit. visws were shipped with P3s.
Certainly true, but still not 64bit and never will be.
--
On Tue, Sep 11, 2007 at 10:34:23PM +0100, Andi Kleen wrote:
> > People do not expect code under arch/i386/ to be used by code under
> > arch/x86_64/ and vice versa.
> >
> > That regularly results in people sending patches that don't compile on
> > the other architecture.
> >
> > With one
On Tue, 11 Sep 2007, Andi Kleen wrote:
>
> Will that cause people to compile test both? I have my doubts that
> will really work.
If people don't compile-test both now, then why would they compile-test
things when merged?
So no, that's not the point.
But at least things like "grep" will
On Tue, Sep 11, 2007 at 10:34:23PM +0100, Andi Kleen wrote:
>
> >
> > People do not expect code under arch/i386/ to be used by code under
> > arch/x86_64/ and vice versa.
> >
> > That regularly results in people sending patches that don't compile on
> > the other architecture.
> >
> > With one
>
> People do not expect code under arch/i386/ to be used by code under
> arch/x86_64/ and vice versa.
>
> That regularly results in people sending patches that don't compile on
> the other architecture.
>
> With one architecture it's much more obvious that the code is shared.
Will that cause
On Tue, 11 Sep 2007, Thomas Gleixner wrote:
>
> I tried to unify the Makefile by using
>
> obj-$(CONFIG_X86_32) +=
> and
> obj-$(CONFIG_X86_64) +=
Don't do that.
I think it would be much better to instead do something like
obj-y += mmconfig_$(CONFIG_WORD_SIZE).o
to make
On Tue, 11 Sep 2007, Sam Ravnborg wrote:
>
> From the mails and discussions I expected it be be obvious what was i386
> only, what was shared and what was x86_64 only.
The problem right now is the *reverse* - even though they are in different
subdirectories (and thus *look* like they are all
On Tue, Sep 11, 2007 at 09:38:10PM +0100, Andi Kleen wrote:
>...
> In the end it won't make much difference where the files are located
> (although I frankly don't see the advantage of this intrusive move).
>
> You always have to at least compile test both if you change one and I doubt
> most
On Tue, Sep 11, 2007 at 11:05:16PM +0200, Sam Ravnborg wrote:
> >
> > As an example, visws.c is as much non-64bit as it is pre-i686.
> Bad example...
> visws is a visws specific file that should naver have allowed
> anywhere outside mach-visws.
Exactly, it's not about 64bit at all.
Similar,
>
> As an example, visws.c is as much non-64bit as it is pre-i686.
Bad example...
visws is a visws specific file that should naver have allowed
anywhere outside mach-visws.
Any link-order issues should have been dealt with in other ways.
Sam
-
To unsubscribe from this list: send the line
> In the filename there is NOTHING for most of
> the non-shared code that tell that this file is
> used by only i386 or x86_64.
Exactly my point from KS. The big mash-up will not really make much difference
in terms of Makefile clarity or whatever Thomas' point was. Apparently he
wanted to
On Tue, Sep 11, 2007 at 10:12:19PM +0200, Sam Ravnborg wrote:
>...
> In a meged x86 tree it would be very beneficial to either include
> in the filename that a specific file is i386 or x86_64 specific or
> stuff them in a separate subdirectory.
>
> If legacy.c numa.c, pcibios.c and visws.c placed
Sam,
On Tue, 2007-09-11 at 22:12 +0200, Sam Ravnborg wrote:
> Hi Thomas et al.
>
> After spending several hours fiddeling with and improving
> the current Makefile for x86_64 I decided to take a closer look
> at the x86 merge og i386 and x86_64.
>
> I took a closer look at x86/pci. There are 16
Hi Thomas et al.
After spending several hours fiddeling with and improving
the current Makefile for x86_64 I decided to take a closer look
at the x86 merge og i386 and x86_64.
I took a closer look at x86/pci. There are 16 C files.
>From the mails and discussions I expected it be be
obvious what
Hi Thomas et al.
After spending several hours fiddeling with and improving
the current Makefile for x86_64 I decided to take a closer look
at the x86 merge og i386 and x86_64.
I took a closer look at x86/pci. There are 16 C files.
From the mails and discussions I expected it be be
obvious what
Sam,
On Tue, 2007-09-11 at 22:12 +0200, Sam Ravnborg wrote:
Hi Thomas et al.
After spending several hours fiddeling with and improving
the current Makefile for x86_64 I decided to take a closer look
at the x86 merge og i386 and x86_64.
I took a closer look at x86/pci. There are 16 C
On Tue, Sep 11, 2007 at 10:12:19PM +0200, Sam Ravnborg wrote:
...
In a meged x86 tree it would be very beneficial to either include
in the filename that a specific file is i386 or x86_64 specific or
stuff them in a separate subdirectory.
If legacy.c numa.c, pcibios.c and visws.c placed in a
In the filename there is NOTHING for most of
the non-shared code that tell that this file is
used by only i386 or x86_64.
Exactly my point from KS. The big mash-up will not really make much difference
in terms of Makefile clarity or whatever Thomas' point was. Apparently he
wanted to
As an example, visws.c is as much non-64bit as it is pre-i686.
Bad example...
visws is a visws specific file that should naver have allowed
anywhere outside mach-visws.
Any link-order issues should have been dealt with in other ways.
Sam
-
To unsubscribe from this list: send the line
On Tue, Sep 11, 2007 at 09:38:10PM +0100, Andi Kleen wrote:
...
In the end it won't make much difference where the files are located
(although I frankly don't see the advantage of this intrusive move).
You always have to at least compile test both if you change one and I doubt
most people
On Tue, 11 Sep 2007, Sam Ravnborg wrote:
From the mails and discussions I expected it be be obvious what was i386
only, what was shared and what was x86_64 only.
The problem right now is the *reverse* - even though they are in different
subdirectories (and thus *look* like they are all
On Tue, 11 Sep 2007, Thomas Gleixner wrote:
I tried to unify the Makefile by using
obj-$(CONFIG_X86_32) +=
and
obj-$(CONFIG_X86_64) +=
Don't do that.
I think it would be much better to instead do something like
obj-y += mmconfig_$(CONFIG_WORD_SIZE).o
to make it
On Tue, Sep 11, 2007 at 11:05:16PM +0200, Sam Ravnborg wrote:
As an example, visws.c is as much non-64bit as it is pre-i686.
Bad example...
visws is a visws specific file that should naver have allowed
anywhere outside mach-visws.
Exactly, it's not about 64bit at all.
Similar, e.g.
People do not expect code under arch/i386/ to be used by code under
arch/x86_64/ and vice versa.
That regularly results in people sending patches that don't compile on
the other architecture.
With one architecture it's much more obvious that the code is shared.
Will that cause people to
On Tue, Sep 11, 2007 at 10:34:23PM +0100, Andi Kleen wrote:
People do not expect code under arch/i386/ to be used by code under
arch/x86_64/ and vice versa.
That regularly results in people sending patches that don't compile on
the other architecture.
With one architecture it's
On Tue, 11 Sep 2007, Andi Kleen wrote:
Will that cause people to compile test both? I have my doubts that
will really work.
If people don't compile-test both now, then why would they compile-test
things when merged?
So no, that's not the point.
But at least things like grep will work
On Tue, Sep 11, 2007 at 10:34:23PM +0100, Andi Kleen wrote:
People do not expect code under arch/i386/ to be used by code under
arch/x86_64/ and vice versa.
That regularly results in people sending patches that don't compile on
the other architecture.
With one architecture it's much
42 matches
Mail list logo
