Ingo Molnar wrote:
( Hey, and maybe someone is crazy enough to try to port the math-emu
code to 64-bit and boot Linux up on 64-bit with all user-space FPU ops
emulated. It would be one of the most useless hacks of all times, and
that certainly has a certain kind of sick appeal to it,
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> As for the Makefiles - I looked at them last time and only issue that
> kept me away for unifying them was that I did not understand the
> linking order requirments and I did not see enough benefit at that
> time to invest the time to unify them.
On Thu, 2008-01-31 at 11:38 +0100, Sam Ravnborg wrote:
> >
> > no strong opinion from me - but i think it should be obvious to the
> > developer when they are looking at a .c file that it's 32-bit only (or
> > 64-bit only). I.e. the default is that whatever .c file we look at is
> > unified -
>
> no strong opinion from me - but i think it should be obvious to the
> developer when they are looking at a .c file that it's 32-bit only (or
> 64-bit only). I.e. the default is that whatever .c file we look at is
> unified - and in that sense relocs.c breaks that general expectation.
I
On Thu, 2008-01-31 at 11:11 +0100, Ingo Molnar wrote:
> * Harvey Harrison <[EMAIL PROTECTED]> wrote:
>
> > > during the big first phase of unification we generally kept file
> > > names untouched if they were only present in one of the previous
> > > architectures. I.e. pure 32-bit and pure
* Harvey Harrison <[EMAIL PROTECTED]> wrote:
> > during the big first phase of unification we generally kept file
> > names untouched if they were only present in one of the previous
> > architectures. I.e. pure 32-bit and pure 64-bit files were not
> > renamed to _32/_64.
> >
> > Now that
On Thu, 2008-01-31 at 10:52 +0100, Ingo Molnar wrote:
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> > why not rename relocs.c to relocs_32.c?
> >
> > it is only used for 32 bit, even it is host app.
>
> during the big first phase of unification we generally kept file names
> untouched if they
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> why not rename relocs.c to relocs_32.c?
>
> it is only used for 32 bit, even it is host app.
during the big first phase of unification we generally kept file names
untouched if they were only present in one of the previous
architectures. I.e. pure
Yinghai Lu wrote:
On Jan 31, 2008 12:33 AM, Chris Snook <[EMAIL PROTECTED]> wrote:
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
but that file is not need for x86_64
Which means there's no conflict with any 64-bit
On Jan 31, 2008 12:33 AM, Chris Snook <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> > why not rename relocs.c to relocs_32.c?
>
> Because we're trying to get rid of all the _32 and _64 files?
but that file is not need for x86_64
YH
--
To unsubscribe from this list: send the line "unsubscribe
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
-- Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
why not rename relocs.c to relocs_32.c?
it is only used for 32 bit, even it is host app.
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
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
-- Chris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Jan 31, 2008 12:33 AM, Chris Snook [EMAIL PROTECTED] wrote:
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
but that file is not need for x86_64
YH
--
To unsubscribe from this list: send the line unsubscribe
Yinghai Lu wrote:
On Jan 31, 2008 12:33 AM, Chris Snook [EMAIL PROTECTED] wrote:
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
but that file is not need for x86_64
Which means there's no conflict with any 64-bit
* Yinghai Lu [EMAIL PROTECTED] wrote:
why not rename relocs.c to relocs_32.c?
it is only used for 32 bit, even it is host app.
during the big first phase of unification we generally kept file names
untouched if they were only present in one of the previous
architectures. I.e. pure 32-bit
* Harvey Harrison [EMAIL PROTECTED] wrote:
during the big first phase of unification we generally kept file
names untouched if they were only present in one of the previous
architectures. I.e. pure 32-bit and pure 64-bit files were not
renamed to _32/_64.
Now that we've got lots
On Thu, 2008-01-31 at 11:11 +0100, Ingo Molnar wrote:
* Harvey Harrison [EMAIL PROTECTED] wrote:
during the big first phase of unification we generally kept file
names untouched if they were only present in one of the previous
architectures. I.e. pure 32-bit and pure 64-bit files
On Thu, 2008-01-31 at 10:52 +0100, Ingo Molnar wrote:
* Yinghai Lu [EMAIL PROTECTED] wrote:
why not rename relocs.c to relocs_32.c?
it is only used for 32 bit, even it is host app.
during the big first phase of unification we generally kept file names
untouched if they were only
no strong opinion from me - but i think it should be obvious to the
developer when they are looking at a .c file that it's 32-bit only (or
64-bit only). I.e. the default is that whatever .c file we look at is
unified - and in that sense relocs.c breaks that general expectation.
I for one
On Thu, 2008-01-31 at 11:38 +0100, Sam Ravnborg wrote:
no strong opinion from me - but i think it should be obvious to the
developer when they are looking at a .c file that it's 32-bit only (or
64-bit only). I.e. the default is that whatever .c file we look at is
unified - and in
* Sam Ravnborg [EMAIL PROTECTED] wrote:
As for the Makefiles - I looked at them last time and only issue that
kept me away for unifying them was that I did not understand the
linking order requirments and I did not see enough benefit at that
time to invest the time to unify them. Each of
Ingo Molnar wrote:
( Hey, and maybe someone is crazy enough to try to port the math-emu
code to 64-bit and boot Linux up on 64-bit with all user-space FPU ops
emulated. It would be one of the most useless hacks of all times, and
that certainly has a certain kind of sick appeal to it,
23 matches
Mail list logo
