Martin Bligh wrote:
> Christoph Lameter wrote:
>> On Fri, 16 Mar 2007, Martin Bligh wrote:
>>
>>> You have to do some sort of lookup anyway, and Andy seemed to have them
>>> all folded into one.
>>
>> What lookup would you need to do? On x86_64 even the TLB use is hidden
>> by the existing 2M
> And those machines are basically identical to perfectly regular i386
> platforms.
For modern (2001+) i386 platforms sure. The problem is the old and the weird.
>
> So the whole argument that it would "diverge" is total crap. It obviously
> won't diverge, simply because the support for old
And those machines are basically identical to perfectly regular i386
platforms.
For modern (2001+) i386 platforms sure. The problem is the old and the weird.
So the whole argument that it would diverge is total crap. It obviously
won't diverge, simply because the support for old setups
Martin Bligh wrote:
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Martin Bligh wrote:
You have to do some sort of lookup anyway, and Andy seemed to have them
all folded into one.
What lookup would you need to do? On x86_64 even the TLB use is hidden
by the existing 2M entries for 1-1
On Fri, 16 Mar 2007, Andi Kleen wrote:
> > In the future it is likely that x86_64 will significantly deviate from
>
> It already is in some cases. And I agree more will happen.
This is a *totally* bogus and idiotic argument.
x86-64 will get new capabilities, BUT IT WILL CONTINUE TO SUPPORT
On Fri, 16 Mar 2007, Andi Kleen wrote:
In the future it is likely that x86_64 will significantly deviate from
It already is in some cases. And I agree more will happen.
This is a *totally* bogus and idiotic argument.
x86-64 will get new capabilities, BUT IT WILL CONTINUE TO SUPPORT OLD
On Fri, 16 Mar 2007, Christoph Lameter wrote:
>
> Yes he has already explained it and I am well aware of the difficulties
> on 32 bit. -> linux-mm archives.
Stop pointing to archives.
If you cannot give a http pointer to a specific thread, don't bother with
the "please real the list" thing
On Fri, 16 Mar 2007, Martin Bligh wrote:
> For starters, you can't do that sparse a mapping on a 32 bit system.
> I'll let Andy explain the rest of it.
Yes he has already explained it and I am well aware of the difficulties
on 32 bit. -> linux-mm archives.
> "the agreement"? So Andy agreed to
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Martin Bligh wrote:
You have to do some sort of lookup anyway, and Andy seemed to have them
all folded into one.
What lookup would you need to do? On x86_64 even the TLB use is
hidden by the existing 2M entries for 1-1 mappings.
Or are you
On Fri, 2007-03-16 at 13:15 -0700, Christoph Lameter wrote:
> On Fri, 16 Mar 2007, Andi Kleen wrote:
> > > x86_64 is going to acquire more functionality that will not be available
> > > for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
> >
> > What advantage would that
On Fri, 16 Mar 2007, David Miller wrote:
> From: Christoph Lameter <[EMAIL PROTECTED]>
> Date: Fri, 16 Mar 2007 13:48:58 -0700 (PDT)
>
> > Please read my posts to linux-mm on that subject. We discussed it last
> > year in detail and the agreement was that the sparsemem crud needs to be
> >
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2007 13:56:13 -0700 (PDT)
> On Fri, 16 Mar 2007, David Miller wrote:
>
> > From: Christoph Lameter <[EMAIL PROTECTED]>
> > Date: Fri, 16 Mar 2007 13:48:58 -0700 (PDT)
> >
> > > Please read my posts to linux-mm on that subject. We
On Fri, 16 Mar 2007, David Miller wrote:
> From: Christoph Lameter <[EMAIL PROTECTED]>
> Date: Fri, 16 Mar 2007 13:52:18 -0700 (PDT)
>
> > Virtual mmap allows holes in the same way as page tables do.
>
> I don't want to take expensive TLB misses to lookup a page.
Ummm. You are missing key
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2007 13:52:18 -0700 (PDT)
> Virtual mmap allows holes in the same way as page tables do.
I don't want to take expensive TLB misses to lookup a page.
Don't force a virtual mapping solution down my throat if that
is not what I believe
On Fri, 16 Mar 2007, David Miller wrote:
> > It is primarily a performance improvement since the sparsemem table
> > lookups would no longer be necessary and it also streamlines other
> > frequent cacheline uses. These page -> page_struct and vice versa
> > operations are key to the
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2007 13:48:58 -0700 (PDT)
> Please read my posts to linux-mm on that subject. We discussed it last
> year in detail and the agreement was that the sparsemem crud needs to be
> taken out. Kame-san posted patches to do that.
Please
On Fri, 16 Mar 2007, Martin Bligh wrote:
> You have to do some sort of lookup anyway, and Andy seemed to have them
> all folded into one.
What lookup would you need to do? On x86_64 even the TLB use is
hidden by the existing 2M entries for 1-1 mappings.
> Or are you trying to avoid this by
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2007 13:15:38 -0700 (PDT)
> On Fri, 16 Mar 2007, Andi Kleen wrote:
>
> > > x86_64 is going to acquire more functionality that will not be available
> > > for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
> >
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Andi Kleen wrote:
x86_64 is going to acquire more functionality that will not be available
for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
What advantage would that have over the current setup?
We already should handle
On Fri, 16 Mar 2007, Andi Kleen wrote:
>
> > x86_64 is going to acquire more functionality that will not be available
> > for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
>
> What advantage would that have over the current setup?
> We already should handle holes
> In the future it is likely that x86_64 will significantly deviate from
It already is in some cases. And I agree more will happen.
> i386. i386 is going to be gradually abandoned because it does not support
> the ever larger memory sizes and be mainly used for embedded devices.
The
In the future it is likely that x86_64 will significantly deviate from
It already is in some cases. And I agree more will happen.
i386. i386 is going to be gradually abandoned because it does not support
the ever larger memory sizes and be mainly used for embedded devices.
The
On Fri, 16 Mar 2007, Andi Kleen wrote:
x86_64 is going to acquire more functionality that will not be available
for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
What advantage would that have over the current setup?
We already should handle holes between nodes
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Andi Kleen wrote:
x86_64 is going to acquire more functionality that will not be available
for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
What advantage would that have over the current setup?
We already should handle
From: Christoph Lameter [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 13:15:38 -0700 (PDT)
On Fri, 16 Mar 2007, Andi Kleen wrote:
x86_64 is going to acquire more functionality that will not be available
for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
What
On Fri, 16 Mar 2007, Martin Bligh wrote:
You have to do some sort of lookup anyway, and Andy seemed to have them
all folded into one.
What lookup would you need to do? On x86_64 even the TLB use is
hidden by the existing 2M entries for 1-1 mappings.
Or are you trying to avoid this by going
On Fri, 16 Mar 2007, David Miller wrote:
It is primarily a performance improvement since the sparsemem table
lookups would no longer be necessary and it also streamlines other
frequent cacheline uses. These page - page_struct and vice versa
operations are key to the performance of
From: Christoph Lameter [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 13:48:58 -0700 (PDT)
Please read my posts to linux-mm on that subject. We discussed it last
year in detail and the agreement was that the sparsemem crud needs to be
taken out. Kame-san posted patches to do that.
Please don't
From: Christoph Lameter [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 13:52:18 -0700 (PDT)
Virtual mmap allows holes in the same way as page tables do.
I don't want to take expensive TLB misses to lookup a page.
Don't force a virtual mapping solution down my throat if that
is not what I believe as
On Fri, 16 Mar 2007, David Miller wrote:
From: Christoph Lameter [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 13:48:58 -0700 (PDT)
Please read my posts to linux-mm on that subject. We discussed it last
year in detail and the agreement was that the sparsemem crud needs to be
taken out.
From: Christoph Lameter [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 13:56:13 -0700 (PDT)
On Fri, 16 Mar 2007, David Miller wrote:
From: Christoph Lameter [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 13:48:58 -0700 (PDT)
Please read my posts to linux-mm on that subject. We discussed it last
On Fri, 16 Mar 2007, David Miller wrote:
From: Christoph Lameter [EMAIL PROTECTED]
Date: Fri, 16 Mar 2007 13:52:18 -0700 (PDT)
Virtual mmap allows holes in the same way as page tables do.
I don't want to take expensive TLB misses to lookup a page.
Ummm. You are missing key details
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Martin Bligh wrote:
You have to do some sort of lookup anyway, and Andy seemed to have them
all folded into one.
What lookup would you need to do? On x86_64 even the TLB use is
hidden by the existing 2M entries for 1-1 mappings.
Or are you
On Fri, 2007-03-16 at 13:15 -0700, Christoph Lameter wrote:
On Fri, 16 Mar 2007, Andi Kleen wrote:
x86_64 is going to acquire more functionality that will not be available
for i386. We plan f.e. to add virtual memmap support for x86_64. Virtual
What advantage would that have over the
On Fri, 16 Mar 2007, Martin Bligh wrote:
For starters, you can't do that sparse a mapping on a 32 bit system.
I'll let Andy explain the rest of it.
Yes he has already explained it and I am well aware of the difficulties
on 32 bit. - linux-mm archives.
the agreement? So Andy agreed to taking
On Fri, 16 Mar 2007, Christoph Lameter wrote:
Yes he has already explained it and I am well aware of the difficulties
on 32 bit. - linux-mm archives.
Stop pointing to archives.
If you cannot give a http pointer to a specific thread, don't bother with
the please real the list thing AT
On Thu, 15 Mar 2007, Steven Rostedt wrote:
> On Thu, 2007-03-15 at 17:06 +0100, Andi Kleen wrote:
>
> > Well I just see a lot of pain from these patches but I doubt
> > they will avoid any bugs. If people don't compile test both
> > archs they will always likely break on another. There are lots
On Wed, 2007-03-14 at 01:08 -0400, Steven Rostedt wrote:
> [Hopefully fixed email client to make it to the list this time]
> [This series has changed by using git-diff -M]
> Seems appropriate, but I really don't care what it's called. One thing about
> this name, is that typing arch/x86 doesn't
On Mar 15 2007 08:59, Linus Torvalds wrote:
>On Thu, 15 Mar 2007, Martin Bligh wrote:
>>
>> Can't we move the shared files into a new shared arch/ subdirectory
>> (ia32_64 or whatever), and have them included from both places?
>
>That's *exactly* what the patches do (except it's called
> You could do both. Have the x86 directory that Linus suggests for shared
> files, then have the build system generate the symlinks for you.
Symlinks are usually a bad idea because they tend to not work with objdirs.
We did that in 2.4.
-Andi
-
To unsubscribe from this list: send the line
On Thu, 2007-03-15 at 18:01 +0100, Andi Kleen wrote:
> > Oops, sorry, you did say "in the includes". Yeah, that holds the same
> > crap that I'm talking about.
>
> It's a simple and obvious solution that does exactly what it is
> supposed to do. Why do you call it crap?
Yes, it's a simple
> Oops, sorry, you did say "in the includes". Yeah, that holds the same
> crap that I'm talking about.
It's a simple and obvious solution that does exactly what it is
supposed to do. Why do you call it crap?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Thu, 2007-03-15 at 12:47 -0400, Steven Rostedt wrote:
> On Thu, 2007-03-15 at 17:06 +0100, Andi Kleen wrote:
>
> > Well I just see a lot of pain from these patches but I doubt
> > they will avoid any bugs. If people don't compile test both
> > archs they will always likely break on another.
Ingo Molnar wrote:
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
symbolic links perhaps? In that case i'd also introduce a common
naming scheme: x86_early_printk.c - to make sure we know it right
away that those files are bi-arch.
Hey, I know! This is a radical idea, but what if we put the
On Thu, 2007-03-15 at 17:06 +0100, Andi Kleen wrote:
> Well I just see a lot of pain from these patches but I doubt
> they will avoid any bugs. If people don't compile test both
> archs they will always likely break on another. There are lots
> of subtle dependencies that are not expressed in
On Thu, 15 Mar 2007, Andi Kleen wrote:
> > That's *exactly* what the patches do (except it's called "arch/x86", which
> > is clearly the best option - please don't use "ia" _anywhere_ except for
> > "ia64", since that's the only architecture that is really "intel
> > architecture").
>
> And
> That's *exactly* what the patches do (except it's called "arch/x86", which
> is clearly the best option - please don't use "ia" _anywhere_ except for
> "ia64", since that's the only architecture that is really "intel
> architecture").
And i860 @)
> > On the downside, it's more ../../.. type
On Thu, 15 Mar 2007, Martin Bligh wrote:
>
> Can't we move the shared files into a new shared arch/ subdirectory
> (ia32_64 or whatever), and have them included from both places?
That's *exactly* what the patches do (except it's called "arch/x86", which
is clearly the best option - please
Linus Torvalds wrote:
On Wed, 14 Mar 2007, Ingo Molnar wrote:
and that's how i think unification of architectures should be done: move
code into kernel/* and drivers/*, _not_ into another architecture. That
way all architectures benefit.
Don't be silly.
Did you even *look* at the patches?
Linus Torvalds wrote:
On Wed, 14 Mar 2007, Ingo Molnar wrote:
and that's how i think unification of architectures should be done: move
code into kernel/* and drivers/*, _not_ into another architecture. That
way all architectures benefit.
Don't be silly.
Did you even *look* at the patches?
On Thu, 15 Mar 2007, Martin Bligh wrote:
Can't we move the shared files into a new shared arch/ subdirectory
(ia32_64 or whatever), and have them included from both places?
That's *exactly* what the patches do (except it's called arch/x86, which
is clearly the best option - please don't
That's *exactly* what the patches do (except it's called arch/x86, which
is clearly the best option - please don't use ia _anywhere_ except for
ia64, since that's the only architecture that is really intel
architecture).
And i860 @)
On the downside, it's more ../../.. type stuff. On the
On Thu, 15 Mar 2007, Andi Kleen wrote:
That's *exactly* what the patches do (except it's called arch/x86, which
is clearly the best option - please don't use ia _anywhere_ except for
ia64, since that's the only architecture that is really intel
architecture).
And i860 @)
Yeah,
On Thu, 2007-03-15 at 17:06 +0100, Andi Kleen wrote:
Well I just see a lot of pain from these patches but I doubt
they will avoid any bugs. If people don't compile test both
archs they will always likely break on another. There are lots
of subtle dependencies that are not expressed in the
Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
symbolic links perhaps? In that case i'd also introduce a common
naming scheme: x86_early_printk.c - to make sure we know it right
away that those files are bi-arch.
Hey, I know! This is a radical idea, but what if we put the
On Thu, 2007-03-15 at 12:47 -0400, Steven Rostedt wrote:
On Thu, 2007-03-15 at 17:06 +0100, Andi Kleen wrote:
Well I just see a lot of pain from these patches but I doubt
they will avoid any bugs. If people don't compile test both
archs they will always likely break on another. There are
Oops, sorry, you did say in the includes. Yeah, that holds the same
crap that I'm talking about.
It's a simple and obvious solution that does exactly what it is
supposed to do. Why do you call it crap?
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Thu, 2007-03-15 at 18:01 +0100, Andi Kleen wrote:
Oops, sorry, you did say in the includes. Yeah, that holds the same
crap that I'm talking about.
It's a simple and obvious solution that does exactly what it is
supposed to do. Why do you call it crap?
Yes, it's a simple solution.
You could do both. Have the x86 directory that Linus suggests for shared
files, then have the build system generate the symlinks for you.
Symlinks are usually a bad idea because they tend to not work with objdirs.
We did that in 2.4.
-Andi
-
To unsubscribe from this list: send the line
On Mar 15 2007 08:59, Linus Torvalds wrote:
On Thu, 15 Mar 2007, Martin Bligh wrote:
Can't we move the shared files into a new shared arch/ subdirectory
(ia32_64 or whatever), and have them included from both places?
That's *exactly* what the patches do (except it's called arch/x86, which
On Wed, 2007-03-14 at 01:08 -0400, Steven Rostedt wrote:
[Hopefully fixed email client to make it to the list this time]
[This series has changed by using git-diff -M]
snip
Seems appropriate, but I really don't care what it's called. One thing about
this name, is that typing arch/x86Tab
On Thu, 15 Mar 2007, Steven Rostedt wrote:
On Thu, 2007-03-15 at 17:06 +0100, Andi Kleen wrote:
Well I just see a lot of pain from these patches but I doubt
they will avoid any bugs. If people don't compile test both
archs they will always likely break on another. There are lots
of
On Mar 14 2007 21:21, Andi Kleen wrote:
>
>> also, having the x32_ and x64_ prefix is a painful daily reminder for
>> all of us changing the architecture that 'this stuff needs to be
>> unified!'.
>
>We would probably stuck with that forever and it just looks ugly.
>Non paravirt xen uses such a
> the basic dynamics of legacies does not change if we have only 50% of
> them: right now x86_64 is just growing its own set of legacies, at the
> same rate as i386 did it 10 years ago.
Modern system are much more similar to each other than older systems
due to Windows forcing them and they
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Andrew's laptop only half a dozen times! ;) But .. in the long run,
> > it's alot easier to think about unified code. 32-bit x86 will
> > certainly stay with us for at least 10-20 years, and the best model
> > for maintainance is having one
> also, having the x32_ and x64_ prefix is a painful daily reminder for
> all of us changing the architecture that 'this stuff needs to be
> unified!'.
We would probably stuck with that forever and it just looks ugly.
Non paravirt xen uses such a setup and I always hated it.
Besides the
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Well, I'd like it to be 100% _eventually_, and just unify the
> > architectures.
>
> ok, having a single bi-arch final tree is indeed intriquing and i didnt
> realize that you were suggesting that. [...]
>
> [...] But this really scares the sh*t
> the x86_64 and i386 trees have diverged quite a bit though, so this will
> be a major logistical undertaking. And with Andi opposed to
> fundamentally it it also lacks a bit of manpower i guess :-/
I'm not fundamentally opposed, just sceptical on the effort:gain ratio.
> Andrew's laptop only
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > of code. i386 is 87847 lines of code, x86_64 is 40978 lines of code,
> > a total of 128825. That means we move about 10% of the code. Not
> > insignificant but not earth-shattering either. With alot more effort
> > (and testing) we could
Andi Kleen wrote:
> Only do it where it makes sense and is not too intrusive.
> Redoing the whole port just for lguest64 is probably not a good idea.
Well, at some point Xen is going to be 64-bit. We need a 64-bit
paravirt_ops, and it looks to me that 90% of the entrypoints will be
more or less
On Wed, Mar 14, 2007 at 09:36:35AM -0400, Steven Rostedt wrote:
> On Wed, 2007-03-14 at 14:05 +0100, Andi Kleen wrote:
> > > The thing is others and I (and you) are working on getting paravirt_ops
> > > working for x86_64. There's a lot of overlap between i386 and x86_64.
> > > Right now the i386
On Wed, Mar 14, 2007 at 11:36:08AM +0100, Andi Kleen wrote:
> Steven Rostedt <[EMAIL PROTECTED]> writes:
> >
> > So I spent last night hacking up something to try to make a common ground
> > for all code that is shared between x86_64 and i386. I called this
> >
> >arch/x86
>
> NACK. I
On Wed, 14 Mar 2007, Ingo Molnar wrote:
>
> then i decided to analyze the patches: currently they move 13452 lines
> of code. i386 is 87847 lines of code, x86_64 is 40978 lines of code, a
> total of 128825. That means we move about 10% of the code. Not
> insignificant but not
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > symbolic links perhaps? In that case i'd also introduce a common
> > naming scheme: x86_early_printk.c - to make sure we know it right
> > away that those files are bi-arch.
>
> Hey, I know! This is a radical idea, but what if we put the name at
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Did you even *look* at the patches?
yes. I am strongly in favor of sharing code - i recently introduced
arch/x86_64/kernel/tsc_sync.c that is shared by i386 too.
So first i wrote a draft email where i told Andi that he's on crack to
NACK it so
On Wed, 14 Mar 2007, Steven Rostedt wrote:
>
> That's created at build time. But I don't see anywhere in a freshly
> cloned repo or fresh untar of the linux tarball, where there exists any
> symbolic links.
There are none.
Symlinks embedded in the source tree tend to be hard to maintain: you
On Wed, 2007-03-14 at 17:33 +0100, Jan Engelhardt wrote:
> On Mar 14 2007 10:46, Steven Rostedt wrote:
> >
> >> symbolic links perhaps? In that case i'd also introduce a common naming
> >> scheme: x86_early_printk.c - to make sure we know it right away that
> >> those files are bi-arch.
> >
>
On Wed, 14 Mar 2007, Jan Engelhardt wrote:
> >
> >Seems appropriate, but I really don't care what it's called. One thing about
> >this name, is that typing arch/x86 doesn't tab complete x86_64 anymore.
> >But if you can think of something better, I'd be happy to apply it.
>
> 80x86
> 8086
>
On Wed, 14 Mar 2007, Ingo Molnar wrote:
>
> symbolic links perhaps? In that case i'd also introduce a common naming
> scheme: x86_early_printk.c - to make sure we know it right away that
> those files are bi-arch.
Hey, I know! This is a radical idea, but what if we put the name at the
head
On Mar 14 2007 10:46, Steven Rostedt wrote:
>
>> symbolic links perhaps? In that case i'd also introduce a common naming
>> scheme: x86_early_printk.c - to make sure we know it right away that
>> those files are bi-arch.
>
>Does the Linux code tree already support sym links? IOW, are there
On Wed, 14 Mar 2007, Ingo Molnar wrote:
>
> and that's how i think unification of architectures should be done: move
> code into kernel/* and drivers/*, _not_ into another architecture. That
> way all architectures benefit.
Don't be silly.
Did you even *look* at the patches?
We're talking
On Wed, 14 Mar 2007, Andi Kleen wrote:
>
> NACK. I think the current ways work just fine.
Andi, the current ways do *not* work just fine.
I don't understand why you have problems with obvious cleanups. You also
nack'ed the file movement to at least make this kind of thing consistent
(ie
On Wed, 2007-03-14 at 14:41 +0100, Ingo Molnar wrote:
> hm. Do you have any numbers handy - what is the end-result of your
> unification work, how many lines of code were unified, compared to the
> total body of code in i386 and x86_64?
Well, I wasn't combining code that wasn't already
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > i agree. We've recently factored out quite a bit of common code
> > between i386 and x86_64 recently: genirq, gtod/clocksource and
> > clockevents.
>
> But those are things that can mostly be shared across all archs.
yeah.
> > and that's how i
On Wed, 2007-03-14 at 14:05 +0100, Andi Kleen wrote:
> > The thing is others and I (and you) are working on getting paravirt_ops
> > working for x86_64. There's a lot of overlap between i386 and x86_64.
> > Right now the i386 is ahead of x86_64 and the code seems to be put more
> > in the
On Wed, 2007-03-14 at 13:53 +0100, Ingo Molnar wrote:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > Steven Rostedt <[EMAIL PROTECTED]> writes:
> > >
> > > So I spent last night hacking up something to try to make a common
> > > ground for all code that is shared between x86_64 and i386. I
>
> The thing is others and I (and you) are working on getting paravirt_ops
> working for x86_64. There's a lot of overlap between i386 and x86_64.
> Right now the i386 is ahead of x86_64 and the code seems to be put more
> in the arch/i386 arch. So now we are going to introduce a
> new ../../i386
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Steven Rostedt <[EMAIL PROTECTED]> writes:
> >
> > So I spent last night hacking up something to try to make a common
> > ground for all code that is shared between x86_64 and i386. I
> > called this
> >
> >arch/x86
>
> NACK. I think the
On Wed, 2007-03-14 at 11:36 +0100, Andi Kleen wrote:
> Steven Rostedt <[EMAIL PROTECTED]> writes:
> >
> > So I spent last night hacking up something to try to make a common ground
> > for all code that is shared between x86_64 and i386. I called this
> >
> >arch/x86
>
> NACK. I think the
Hi,
I am newbie developing a routing application which
needs three features;
1. if the fib lookup fails, my application needs to know about using
preferably
netlink, -- any direction to some sample code or files in the kernel???
2. I need a counter recording the hits a fib entry is chosen for
Steven Rostedt <[EMAIL PROTECTED]> writes:
>
> So I spent last night hacking up something to try to make a common ground
> for all code that is shared between x86_64 and i386. I called this
>
>arch/x86
NACK. I think the current ways work just fine.
-Andi
-
To unsubscribe from this list:
On Mar 14 2007 01:08, Steven Rostedt wrote:
>
>So I spent last night hacking up something to try to make a common ground
>for all code that is shared between x86_64 and i386. I called this
>
> arch/x86
>
>Seems appropriate, but I really don't care what it's called. One thing about
>this name,
On Mar 14 2007 01:08, Steven Rostedt wrote:
So I spent last night hacking up something to try to make a common ground
for all code that is shared between x86_64 and i386. I called this
arch/x86
Seems appropriate, but I really don't care what it's called. One thing about
this name, is that
Steven Rostedt [EMAIL PROTECTED] writes:
So I spent last night hacking up something to try to make a common ground
for all code that is shared between x86_64 and i386. I called this
arch/x86
NACK. I think the current ways work just fine.
-Andi
-
To unsubscribe from this list: send
Hi,
I am newbie developing a routing application which
needs three features;
1. if the fib lookup fails, my application needs to know about using
preferably
netlink, -- any direction to some sample code or files in the kernel???
2. I need a counter recording the hits a fib entry is chosen for
On Wed, 2007-03-14 at 11:36 +0100, Andi Kleen wrote:
Steven Rostedt [EMAIL PROTECTED] writes:
So I spent last night hacking up something to try to make a common ground
for all code that is shared between x86_64 and i386. I called this
arch/x86
NACK. I think the current ways
* Andi Kleen [EMAIL PROTECTED] wrote:
Steven Rostedt [EMAIL PROTECTED] writes:
So I spent last night hacking up something to try to make a common
ground for all code that is shared between x86_64 and i386. I
called this
arch/x86
NACK. I think the current ways work just
The thing is others and I (and you) are working on getting paravirt_ops
working for x86_64. There's a lot of overlap between i386 and x86_64.
Right now the i386 is ahead of x86_64 and the code seems to be put more
in the arch/i386 arch. So now we are going to introduce a
new ../../i386 hack
On Wed, 2007-03-14 at 13:53 +0100, Ingo Molnar wrote:
* Andi Kleen [EMAIL PROTECTED] wrote:
Steven Rostedt [EMAIL PROTECTED] writes:
So I spent last night hacking up something to try to make a common
ground for all code that is shared between x86_64 and i386. I
called this
On Wed, 2007-03-14 at 14:05 +0100, Andi Kleen wrote:
The thing is others and I (and you) are working on getting paravirt_ops
working for x86_64. There's a lot of overlap between i386 and x86_64.
Right now the i386 is ahead of x86_64 and the code seems to be put more
in the arch/i386 arch.
1 - 100 of 122 matches
Mail list logo
