Skip to contentSkip to conversation

Location of init_task_union

DISCUSSION Ralf Baechle 1 participant 2 messages Nov 23, 1999 – Nov 24, 1999 7 messages not in the archive MIPS

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw
Quoted 9 lines · Bradley D. LaRonde
Quoted 6 lines
Quoted 3 lines

I can easily move it to .data or .data.init_task like i386, but I'm wondering if there is some special reason why it is in .text on mips and .data on i386.

Doesn't matter when it ends up, it only needs to be 8kb aligned which is why we have to do such silly things.

i386 does it by putting it in it's own segment, then aligning that segment in the linker script. Can we switch to that way?

Yes. I already did this in my private source for another, MIPS64 related reason.

Ralf

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#8 lore raw
Quoted 7 lines · Gleb O. Raiko
Quoted 1 line · Bradley D. LaRonde

So when do we get this for mips32? :-)

The patch that moves cpu detection to plain C already exists and it's easy to port other stuff from mips64. The only problem I didn't apply the patch yet is I have to make pci operable again and I am busy in that direction.

I plan to commit 2.3.21 into CVS this evening. I do this mostly in order to keep the 32-bit tree upto sync with Linus. This will also contain a pile of 64-bit stuff, just not all of it nor be complete. I hope that some people will take this as inspiration and fold some of the cleanups back into the 32-bit tree while I continue to fight in the endless [1] 64-bit address space ...

Ralf

[1] Where endless is defined as 1TB.