about relocs.c on x86

about relocs.c on x86

[Yinghai Lu]

why not rename relocs.c to relocs_32.c?

it is only used for 32 bit, even it is host app.

YH

Re: about relocs.c on x86

[Chris Snook]

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

Re: about relocs.c on x86

[Yinghai Lu]

On Jan 31, 2008 12:33 AM, Chris Snook <csnook@redhat.com> 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

Re: about relocs.c on x86

[Chris Snook]

Yinghai Lu wrote:
> On Jan 31, 2008 12:33 AM, Chris Snook <csnook@redhat.com> 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

Re: about relocs.c on x86

[Ingo Molnar]

* Yinghai Lu <yhlu.kernel@gmail.com> 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

Re: about relocs.c on x86

[Harvey Harrison]

On Thu, 2008-01-31 at 10:52 +0100, Ingo Molnar wrote:
> * Yinghai Lu <yhlu.kernel@gmail.com> 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

Re: about relocs.c on x86

[Ingo Molnar]

* Harvey Harrison <harvey.harrison@gmail.com> 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

Re: about relocs.c on x86

[Harvey Harrison]

On Thu, 2008-01-31 at 11:11 +0100, Ingo Molnar wrote:
> * Harvey Harrison <harvey.harrison@gmail.com> 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

Re: about relocs.c on x86

[Sam Ravnborg]

> 
> 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

Re: about relocs.c on x86

[Harvey Harrison]

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

Re: about relocs.c on x86

[Ingo Molnar]

* Sam Ravnborg <sam@ravnborg.org> 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

Re: about relocs.c on x86

[H. Peter Anvin]

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