[PATCH 3/3] m68k: compile fix - updated vmlinux.lds to include LOCK_TEXT

[PATCH 3/3] m68k: compile fix - updated vmlinux.lds to include LOCK_TEXT

[Al Viro]

... and that should get m68k to build with gcc 3.x in mainline.  gcc4
fixes are separate story.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
[rz: BTW, proposed variant of thread_info patchset is available for review,
see ftp.linux.org.uk/pub/people/viro/task_thread_info-mbox...  Doesn't
do any incompatible changes, mergable at leisure, reduces the remaining
renaming to ~50 lines - the only chunk that will have to go at 2.6.16...]

 arch/m68k/kernel/vmlinux-std.lds  |    1 +
 arch/m68k/kernel/vmlinux-sun3.lds |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

cc448b2f798627bc448ca14f3d6fb39f356bb117
diff --git a/arch/m68k/kernel/vmlinux-std.lds b/arch/m68k/kernel/vmlinux-std.lds
index e58654f..69d1d3d 100644
--- a/arch/m68k/kernel/vmlinux-std.lds
+++ b/arch/m68k/kernel/vmlinux-std.lds
@@ -13,6 +13,7 @@ SECTIONS
   .text : {
 	*(.text)
 	SCHED_TEXT
+	LOCK_TEXT
 	*(.fixup)
 	*(.gnu.warning)
 	} :text = 0x4e75
diff --git a/arch/m68k/kernel/vmlinux-sun3.lds b/arch/m68k/kernel/vmlinux-sun3.lds
index cc37e8d..f814e66 100644
--- a/arch/m68k/kernel/vmlinux-sun3.lds
+++ b/arch/m68k/kernel/vmlinux-sun3.lds
@@ -14,6 +14,7 @@ SECTIONS
 	*(.head)
 	*(.text)
 	SCHED_TEXT
+	LOCK_TEXT
 	*(.fixup)
 	*(.gnu.warning)
 	} :text = 0x4e75
-- 
0.99.9.GIT

Re: [PATCH 3/3] m68k: compile fix - updated vmlinux.lds to include LOCK_TEXT

[Roman Zippel]

Hi,

On Thu, 15 Dec 2005, Al Viro wrote:

> [rz: BTW, proposed variant of thread_info patchset is available for review,
> see ftp.linux.org.uk/pub/people/viro/task_thread_info-mbox...  Doesn't
> do any incompatible changes, mergable at leisure, reduces the remaining
> renaming to ~50 lines - the only chunk that will have to go at 2.6.16...]

Looks good, but what I still don't understand is why you couldn't do this 
on top of my patches. I'm waiting now to get all this resolved, before I 
want to queue any other large patches.

bye, Roman

Re: [PATCH 3/3] m68k: compile fix - updated vmlinux.lds to include LOCK_TEXT

[Roman Zippel]

Hi,

On Thu, 15 Dec 2005, Al Viro wrote:

> [rz: BTW, proposed variant of thread_info patchset is available for review,
> see ftp.linux.org.uk/pub/people/viro/task_thread_info-mbox...

BTW please fix the comment in the last patch, {get,put}_thread_info() 
didn't come from the m68k tree, so don't blame it for this stuff.
The thread_info stuff went through a number changes during 2.5.xx and it's 
a leftover from this.

bye, Roman

Re: [PATCH 3/3] m68k: compile fix - updated vmlinux.lds to include LOCK_TEXT

[Al Viro]

On Thu, Dec 15, 2005 at 02:12:34PM +0100, Roman Zippel wrote:
> Hi,
> 
> On Thu, 15 Dec 2005, Al Viro wrote:
> 
> > [rz: BTW, proposed variant of thread_info patchset is available for review,
> > see ftp.linux.org.uk/pub/people/viro/task_thread_info-mbox...
> 
> BTW please fix the comment in the last patch, {get,put}_thread_info() 
> didn't come from the m68k tree, so don't blame it for this stuff.
> The thread_info stuff went through a number changes during 2.5.xx and it's 
> a leftover from this.

<goes to check history>

My apologies - that junk predates the events I'd been thinking about.
The rest of comments still stands - it was never used since the moment
of introduction...

Speaking of hardirq.h - come on; even argument about check being not
in the same place where the value is defined...

* we compare NR_IRQS and HARDIRQ_BITS
* one of them is defined in irq.h, another - in hardirq.h
* due to current header ordering, comparison works in irq.h and not in
hardirq.h
* if you change that ordering (which is a *big* patchset, even if you
manage to keep it with zero impact on other architectures) so that check
can go in either place, you can always put it into the place where it
would make more sense in new header ordering; it's not going to be make
patch heavier.

IMO for now it's a no-brainer - compile fix that moves comparison to the
place where another side of comparison is defined  vs.  header ordering
rework...  Sorry.

Re: [PATCH 3/3] m68k: compile fix - updated vmlinux.lds to include LOCK_TEXT

[Roman Zippel]

Hi,

On Thu, 15 Dec 2005, Al Viro wrote:

> Speaking of hardirq.h - come on; even argument about check being not
> in the same place where the value is defined...
> 
> * we compare NR_IRQS and HARDIRQ_BITS
> * one of them is defined in irq.h, another - in hardirq.h
> * due to current header ordering, comparison works in irq.h and not in
> hardirq.h

I rechecked what I did in the m68k tree. The basic idea is that 
<asm/irq.h> is mostly a private header (basically our <linux/irq.h>),
so if we move something around I would prefer the NR_IRQS definition.
I tried that, but it broke a few other dependencies, so I changed it that 
the (public) hardirq.h includes the (private) irq.h.

Basically what we need is a clear separation between private/public and 
low/high level irq header. For example <linux/interrupt.h> is high level 
header (it even pulls in <linux/sched.h>!) but it defines irqreturn_t 
which is also useful in lower level irq headers.

Christoph, what exactly is your plan regarding irq.h/hardirq.h?

bye, Roman