why not rename relocs.c to relocs_32.c?
it is only used for 32 bit, even it is host app.
YH
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
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
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 code, and thus no reason
to break it out into a _32 file.
-- Chris
* 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 and pure 64-bit files were not renamed
to _32/_64.
Now that we've got lots of unified 32/64-bit files it might make sense
to rename the 'standalone' ones into _32/_64 if they share the same
directory with 32/64-bit source files - to reduce the confusion. And
given that for example arch/x86/boot/compressed/misc.c is unified while
arch/x86/boot/compressed/relocs.c is 32-bit only, i'd agree with your
observation. Feel free to send a rename patch for such cases.
Ingo
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 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 of unified 32/64-bit files it might make sense
> to rename the 'standalone' ones into _32/_64 if they share the same
> directory with 32/64-bit source files - to reduce the confusion. And
> given that for example arch/x86/boot/compressed/misc.c is unified while
> arch/x86/boot/compressed/relocs.c is 32-bit only, i'd agree with your
> observation. Feel free to send a rename patch for such cases.
I'd argue that eliminating the _32/_64 suffixes through unification and
not adding any more would be better. Renaming at this point seems like
the wrong side of the cost/benefit line. When the makefiles finally get
unified, that would be a natural list of what is 32 bit-only and what
is 64 bit-only, and additional suffixes wouldn't add much to that.
Just another voice,
Harvey
* 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 of unified 32/64-bit files it might make
> > sense to rename the 'standalone' ones into _32/_64 if they share the
> > same directory with 32/64-bit source files - to reduce the
> > confusion. And given that for example
> > arch/x86/boot/compressed/misc.c is unified while
> > arch/x86/boot/compressed/relocs.c is 32-bit only, i'd agree with
> > your observation. Feel free to send a rename patch for such cases.
>
> I'd argue that eliminating the _32/_64 suffixes through unification
> and not adding any more would be better. Renaming at this point seems
> like the wrong side of the cost/benefit line. When the makefiles
> finally get unified, that would be a natural list of what is 32
> bit-only and what is 64 bit-only, and additional suffixes wouldn't add
> much to that.
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.
In fact renaming it to _32.c might spur its unification: people might
say "hm, this would be handy on 64-bit as well". We might even do that
to directories - so that for example arch/x86/math-emu/ would become
arch/x86/match-emu_32/.
( 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, doesnt it? ;-))
but it's really not a big issue, we can certainly leave it alone and
observe the situation as more stuff gets unified. I'd expect it all fall
into place naturally.
Ingo
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 were not
> > > renamed to _32/_64.
> > >
> > > Now that we've got lots of unified 32/64-bit files it might make
> > > sense to rename the 'standalone' ones into _32/_64 if they share the
> > > same directory with 32/64-bit source files - to reduce the
> > > confusion. And given that for example
> > > arch/x86/boot/compressed/misc.c is unified while
> > > arch/x86/boot/compressed/relocs.c is 32-bit only, i'd agree with
> > > your observation. Feel free to send a rename patch for such cases.
> >
> > I'd argue that eliminating the _32/_64 suffixes through unification
> > and not adding any more would be better. Renaming at this point seems
> > like the wrong side of the cost/benefit line. When the makefiles
> > finally get unified, that would be a natural list of what is 32
> > bit-only and what is 64 bit-only, and additional suffixes wouldn't add
> > much to that.
>
> 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.
>
> In fact renaming it to _32.c might spur its unification: people might
> say "hm, this would be handy on 64-bit as well". We might even do that
> to directories - so that for example arch/x86/math-emu/ would become
> arch/x86/match-emu_32/.
They could just as easily do that in the original file rather than
renaming it once and then renaming it again someday when it has 64
bit functionality. It's the potential for this double-rename that
really turns me off the idea.
>
> ( 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, doesnt it? ;-))
>
> but it's really not a big issue, we can certainly leave it alone and
> observe the situation as more stuff gets unified. I'd expect it all fall
> into place naturally.
Again, I can't tell people how to spend their time, but there isn't much
benefit over checking the makefile to see if it is shared for this case
that I can see.
IMHO
Harvey
>
> 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 would like to see when stuff is 32 bit only and when
shared across 32 and 64 bit.
And this type of info is useful when I do greps so hiding the information
in a Makefiel is then no good.
It helps your understanding when you get the most correct picture of
where a certain symbol is used - a functionality I often need.
And this is by no menas limited to a narrow x86 view but across
the full kernel.
So I, and this is no news for Ingo, would like to see what is
solely for 32 bit to be marked as such.
And we are heading with full speed to the situation for x86 where
the number of foo_32.c, foo_64.c are minimal.
But that said we will likely see a small decrease in speed now.
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 the remaining Makefile should be unifyable in less
than 10 steps each. It is just work that are waitng to be done.
Sam
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 that sense relocs.c breaks that general expectation.
>
> I for one would like to see when stuff is 32 bit only and when
> shared across 32 and 64 bit.
> And this type of info is useful when I do greps so hiding the information
> in a Makefiel is then no good.
>
> It helps your understanding when you get the most correct picture of
> where a certain symbol is used - a functionality I often need.
> And this is by no menas limited to a narrow x86 view but across
> the full kernel.
>
> So I, and this is no news for Ingo, would like to see what is
> solely for 32 bit to be marked as such.
Consider me outnumbered then, no worries.
>
> And we are heading with full speed to the situation for x86 where
> the number of foo_32.c, foo_64.c are minimal.
> But that said we will likely see a small decrease in speed now.
Well, we're doing our best ;-)
>
> 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 the remaining Makefile should be unifyable in less
> than 10 steps each. It is just work that are waitng to be done.
The continued unification will probably make this obvious over time
anyway.
Cheers,
Harvey
* 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 the remaining Makefile
> should be unifyable in less than 10 steps each. It is just work that
> are waitng to be done.
the only real issue i remember in this area are hidden link dependencies
in terms of ordering init sequences.
and there's just no other sane approach here but to do finegrained
changes (so that any breakage remains bisectable) and take the plunge
down that road. Any implicit link dependency is a bug in the waiting
anyway, which we want to fix. So feel free to unify this area, whenver
you find the time.
Ingo
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, doesnt it? ;-))
>
It'd take a lot of work, since the x86-64 ABI requires SSE2.
-hpa