Getting kernel.org kernel to build for m68k?

Getting kernel.org kernel to build for m68k?

[Dan Kegel]

Hi Geert,
I see from
http://linux-m68k-cvs.apia.dhs.org/~geert/linux-m68k-2.6.x-merging/
that you're merging patches back into Linus' kernel.  Great!

I noticed today that Linus's m68k kernel can't be built (at least with gcc-3.4.1).

The first problem I ran into,
   CC      arch/m68k/kernel/asm-offsets.s
   In file included from include/linux/spinlock.h:12,
                  from include/linux/capability.h:45,
                  from include/linux/sched.h:7,
                  from arch/m68k/kernel/asm-offsets.c:12:
   include/linux/thread_info.h:30: error: parse error before '{' token
is solved already in the m68k tree.
(In particular,
the #ifndef __HAVE_THREAD_FUNCTIONS ... #endif in
http://linux-m68k-cvs.apia.dhs.org/c/cvsweb/linux/include/linux/thread_info.h?rev=1.5;content-type=text%2Fplain
probably solves it.)
There are other problems after that.

Any chance you could spend a bit of time sending Linus enough
patches for his kernel to build for m68k, if not run?
It would be helpful to my crosstool project (I'm adding a
"can this toolchain build the kernel" test, and it's a lot
easier if I can count on the kernel.org tree at least building).

Thanks,
Dan

-- 
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change

Re: Getting kernel.org kernel to build for m68k?

[Geert Uytterhoeven]

On Tue, 31 Aug 2004, Dan Kegel wrote:
> I noticed today that Linus's m68k kernel can't be built (at least with gcc-3.4.1).
>
> The first problem I ran into,
>    CC      arch/m68k/kernel/asm-offsets.s
>    In file included from include/linux/spinlock.h:12,
>                   from include/linux/capability.h:45,
>                   from include/linux/sched.h:7,
>                   from arch/m68k/kernel/asm-offsets.c:12:
>    include/linux/thread_info.h:30: error: parse error before '{' token
> is solved already in the m68k tree.
> (In particular,
> the #ifndef __HAVE_THREAD_FUNCTIONS ... #endif in
> http://linux-m68k-cvs.apia.dhs.org/c/cvsweb/linux/include/linux/thread_info.h?rev=1.5;content-type=text%2Fplain
> probably solves it.)
> There are other problems after that.

Roman Zippel changed the threading stuff on m68k. Since it would affect other
architectures, I never submitted it on my own.

In short, we never really compile this code, since the m68k tree doesn't use it
anymore. And yes, it even fails with older compiler versions, like 2.95.2.

> Any chance you could spend a bit of time sending Linus enough
> patches for his kernel to build for m68k, if not run?

I'll make sure a plain kernel.org kernel can build an m68k kernel.

> It would be helpful to my crosstool project (I'm adding a
> "can this toolchain build the kernel" test, and it's a lot
> easier if I can count on the kernel.org tree at least building).

Great!

Let's hope people start doing the other way around as well, so I don't have to
run allyesconfigs to catch bugs in non-m68k drivers ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Getting kernel.org kernel to build for m68k?

[Geert Uytterhoeven]

On Wed, 1 Sep 2004, Geert Uytterhoeven wrote:
> On Tue, 31 Aug 2004, Dan Kegel wrote:
> > I noticed today that Linus's m68k kernel can't be built (at least with gcc-3.4.1).
> >
> > The first problem I ran into,
> >    CC      arch/m68k/kernel/asm-offsets.s
> >    In file included from include/linux/spinlock.h:12,
> >                   from include/linux/capability.h:45,
> >                   from include/linux/sched.h:7,
> >                   from arch/m68k/kernel/asm-offsets.c:12:
> >    include/linux/thread_info.h:30: error: parse error before '{' token
> > is solved already in the m68k tree.
> > (In particular,
> > the #ifndef __HAVE_THREAD_FUNCTIONS ... #endif in
> > http://linux-m68k-cvs.apia.dhs.org/c/cvsweb/linux/include/linux/thread_info.h?rev=1.5;content-type=text%2Fplain
> > probably solves it.)
> > There are other problems after that.
>
> Roman Zippel changed the threading stuff on m68k. Since it would affect other
> architectures, I never submitted it on my own.
>
> In short, we never really compile this code, since the m68k tree doesn't use it
> anymore. And yes, it even fails with older compiler versions, like 2.95.2.

The second part doesn't seem to be true: the code is used. And it does compile
after applying the fixes below, even with gcc 3.4.1.

> > Any chance you could spend a bit of time sending Linus enough
> > patches for his kernel to build for m68k, if not run?
>
> I'll make sure a plain kernel.org kernel can build an m68k kernel.

The patch below makes the plain kernel.org 2.6.8.1 compile for m68k,
using gcc 2.95.2 or 3.3.3 (3.4.1 needs a few more changes in random
places). The resulting kernel (I booted the gcc 2.95.2 case) works fine on my
Amiga.

It's more or less the patch created by Matthias Urlichs last year, so
the credits are his:

| This change implements a reasonable compromise between the task_info->flags
| variable in other ports, which is too much work in the syscall path on m68k,
| and moving the whole structure to thread_struct, which is way too intrusive
| on other ports.

The patch does affect generic code a bit, but the collateral damage is
kept to a minimum.

We can still keep Roman's thread info abstractions[*] in Linux/m68k CVS, but
I'd really like the plain kernel.org kernel to be in a working state as well.
That way more people may do cross-compile tests for m68k.

Hence if no one objects, I'll submit the patch to Andrew and Linus.

All comments are welcome!

--- linux-2.6.8.1/arch/m68k/kernel/asm-offsets.c	2004-04-28 15:48:59.000000000 +0200
+++ linux-m68k-2.6.8.1/arch/m68k/kernel/asm-offsets.c	2004-09-05 12:04:00.000000000 +0200
@@ -31,6 +31,7 @@ int main(void)
 	DEFINE(TASK_SIGPENDING, offsetof(struct task_struct, thread.work.sigpending));
 	DEFINE(TASK_NOTIFY_RESUME, offsetof(struct task_struct, thread.work.notify_resume));
 	DEFINE(TASK_THREAD, offsetof(struct task_struct, thread));
+	DEFINE(TASK_TINFO, offsetof(struct task_struct, thread_info));
 	DEFINE(TASK_MM, offsetof(struct task_struct, mm));
 	DEFINE(TASK_ACTIVE_MM, offsetof(struct task_struct, active_mm));

@@ -45,6 +46,9 @@ int main(void)
 	DEFINE(THREAD_FPCNTL, offsetof(struct thread_struct, fpcntl));
 	DEFINE(THREAD_FPSTATE, offsetof(struct thread_struct, fpstate));

+	/* offsets into the thread_info struct */
+	DEFINE(TINFO_PREEMPT, offsetof(struct thread_info, preempt_count));
+
 	/* offsets into the pt_regs */
 	DEFINE(PT_D0, offsetof(struct pt_regs, d0));
 	DEFINE(PT_ORIG_D0, offsetof(struct pt_regs, orig_d0));
--- linux-2.6.8.1/arch/m68k/kernel/entry.S	2004-05-24 11:13:22.000000000 +0200
+++ linux-m68k-2.6.8.1/arch/m68k/kernel/entry.S	2004-09-02 20:13:12.000000000 +0200
@@ -134,13 +134,13 @@ ENTRY(system_call)

 syscall_exit_work:
 	btst	#5,%sp@(PT_SR)		| check if returning to kernel
-	bnes	1b			| if so, skip resched, signals
+	bnes	1b			| if so, skip everything
 	tstw	%d0
-	jeq	do_signal_return
+	jeq	do_signal_return | jump if only sig_pending or notify_resume
 	tstb	%d0
-	jne	do_delayed_trace
+	jne	do_delayed_trace | jump if delayed_trace

-	pea	resume_userspace
+	pea	resume_userspace | need_resched is set
 	jmp	schedule

 ret_from_exception:
@@ -223,10 +223,14 @@ ENTRY(nmi_handler)
 */
 inthandler:
 	SAVE_ALL_INT
-	GET_CURRENT(%d0)
-	addqb	#1,%curptr@(TASK_INFO+TINFO_PREEMPT+2)
-					|  put exception # in d0
-	bfextu %sp@(PT_VECTOR){#4,#10},%d0
+	/* GET_CURRENT(%d0) */
+	movel	%sp,%d0
+	andw	#-THREAD_SIZE,%d0
+	movel	%d0,%a1
+	addqb	#1,%a1@(TINFO_PREEMPT+2)
+	movel	%a1@,%curptr
+
+	bfextu	%sp@(PT_VECTOR){#4,#10},%d0 |  put exception # in d0

 	movel	%sp,%sp@-
 	movel	%d0,%sp@-		|  put vector # on stack
@@ -243,7 +247,8 @@ inthandler:
 3:	addql	#8,%sp			|  pop parameters off stack

 ret_from_interrupt:
-	subqb	#1,%curptr@(TASK_INFO+TINFO_PREEMPT+2)
+	movel	%curptr@(TASK_TINFO),%a1
+	subqb	#1,%a1@(TINFO_PREEMPT+2)
 	jeq	1f
 2:
 	RESTORE_ALL
--- linux-2.6.8.1/include/asm-m68k/processor.h	2004-04-28 15:49:03.000000000 +0200
+++ linux-m68k-2.6.8.1/include/asm-m68k/processor.h	2004-09-02 20:29:32.000000000 +0200
@@ -84,7 +84,6 @@ struct thread_struct {
 	ksp:	sizeof(init_stack) + (unsigned long) init_stack,	\
 	sr:	PS_S,							\
 	fs:	__KERNEL_DS,						\
-	info:	INIT_THREAD_INFO(init_task)				\
 }

 /*
--- linux-2.6.8.1/include/asm-m68k/thread_info.h	2004-05-24 11:13:53.000000000 +0200
+++ linux-m68k-2.6.8.1/include/asm-m68k/thread_info.h	2004-09-05 12:19:47.000000000 +0200
@@ -6,7 +6,7 @@
 #include <asm/page.h>

 struct thread_info {
-	struct task_struct	*task;		/* main task structure */
+	struct task_struct	*task;		/* main task structure, must be first! */
 	struct exec_domain	*exec_domain;	/* execution domain */
 	__s32			preempt_count; /* 0 => preemptable, <0 => BUG */
 	__u32 cpu; /* should always be 0 on m68k */
@@ -21,7 +21,8 @@ struct thread_info {
 {						\
 	.task		= &tsk,			\
 	.exec_domain	= &default_exec_domain,	\
-	.restart_block = {			\
+	.preempt_count	= 1,			\
+	.restart_block	= {			\
 		.fn = do_no_restart_syscall,	\
 	},					\
 }
@@ -35,10 +36,11 @@ struct thread_info {
 #define free_thread_info(ti)  free_pages((unsigned long)(ti),1)
 #endif /* PAGE_SHIFT == 13 */

-//#define init_thread_info	(init_task.thread.info)
+#define init_thread_info	(init_thread_union.thread_info)
 #define init_stack		(init_thread_union.stack)

-#define current_thread_info()	(current->thread_info)
+register __u32 current_thread_info_reg asm("sp");
+#define current_thread_info()	((struct thread_info *)(current_thread_info_reg & ~0x1fff))


 #define __HAVE_THREAD_FUNCTIONS
@@ -91,8 +93,12 @@ extern int thread_flag_fixme(void);
 })

 #define __get_set_tsk_thread_flag(tsk, flag, val) ({	\
-	int __res = __get_tsk_thread_flag(tsk, flag);	\
+	int __res;					\
+	unsigned long __flags; \
+	local_irq_save(__flags);  \
+	__res = __get_tsk_thread_flag(tsk, flag);	\
 	__set_tsk_thread_flag(tsk, flag, val);		\
+	local_irq_restore(__flags);  \
 	__res;						\
 })

@@ -105,7 +111,4 @@ extern int thread_flag_fixme(void);
 #define clear_thread_flag(flag) clear_tsk_thread_flag(current, flag)
 #define test_thread_flag(flag) test_tsk_thread_flag(current, flag)

-#define set_need_resched() set_thread_flag(TIF_NEED_RESCHED)
-#define clear_need_resched() clear_thread_flag(TIF_NEED_RESCHED)
-
 #endif	/* _ASM_M68K_THREAD_INFO_H */
--- linux-2.6.8.1/include/linux/sched.h	2004-08-04 12:14:38.000000000 +0200
+++ linux-m68k-2.6.8.1/include/linux/sched.h	2004-09-04 21:18:59.000000000 +0200
@@ -977,6 +977,7 @@ static inline struct mm_struct * get_tas
 	return mm;
 }

+#ifndef __HAVE_THREAD_FUNCTIONS

 /* set thread flags in other task's structures
  * - see asm/thread_info.h for TIF_xxxx flags available
@@ -1006,6 +1007,8 @@ static inline int test_tsk_thread_flag(s
 	return test_ti_thread_flag(tsk->thread_info,flag);
 }

+#endif	/* __HAVE_THREAD_FUNCTIONS */
+
 static inline void set_tsk_need_resched(struct task_struct *tsk)
 {
 	set_tsk_thread_flag(tsk,TIF_NEED_RESCHED);
--- linux-2.6.8.1/include/linux/thread_info.h	2004-04-27 20:42:22.000000000 +0200
+++ linux-m68k-2.6.8.1/include/linux/thread_info.h	2004-09-04 21:24:36.000000000 +0200
@@ -21,6 +21,7 @@ extern long do_no_restart_syscall(struct
 #include <asm/thread_info.h>

 #ifdef __KERNEL__
+#ifndef __HAVE_THREAD_FUNCTIONS

 /*
  * flag set/clear/test wrappers
@@ -77,16 +78,11 @@ static inline int test_ti_thread_flag(st
 	return test_bit(flag,&ti->flags);
 }

-static inline void set_need_resched(void)
-{
-	set_thread_flag(TIF_NEED_RESCHED);
-}
+#endif	/* __HAVE_THREAD_FUNCTIONS */

-static inline void clear_need_resched(void)
-{
-	clear_thread_flag(TIF_NEED_RESCHED);
-}
+#define set_need_resched() set_thread_flag(TIF_NEED_RESCHED)
+#define clear_need_resched(void) clear_thread_flag(TIF_NEED_RESCHED)

-#endif
+#endif	/* __KERNEL__ */

 #endif /* _LINUX_THREAD_INFO_H */

Gr{oetje,eeting}s,

						Geert

[*] For reference:

    http://linux-m68k-cvs.ubb.ca/~geert/linux-m68k-2.6.x-merging/POSTPONED/156-thread_info.diff

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Getting kernel.org kernel to build for m68k?

[Matthias Urlichs]

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

Hi,

Geert Uytterhoeven:
> Hence if no one objects, I'll submit the patch to Andrew and Linus.
> 
> All comments are welcome!
> 
Go for it.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Getting kernel.org kernel to build for m68k?

[Christoph Hellwig]

> Hence if no one objects, I'll submit the patch to Andrew and Linus.

the common code changes below are not okay.  Please fir m68k into one of
the schemes we have for thread_info/task_struct already.


> --- linux-2.6.8.1/include/linux/sched.h	2004-08-04 12:14:38.000000000 +0200
> +++ linux-m68k-2.6.8.1/include/linux/sched.h	2004-09-04 21:18:59.000000000 +0200
> @@ -977,6 +977,7 @@ static inline struct mm_struct * get_tas
>  	return mm;
>  }
> 
> +#ifndef __HAVE_THREAD_FUNCTIONS
> 
>  /* set thread flags in other task's structures
>   * - see asm/thread_info.h for TIF_xxxx flags available
> @@ -1006,6 +1007,8 @@ static inline int test_tsk_thread_flag(s
>  	return test_ti_thread_flag(tsk->thread_info,flag);
>  }
> 
> +#endif	/* __HAVE_THREAD_FUNCTIONS */
> +
>  static inline void set_tsk_need_resched(struct task_struct *tsk)
>  {
>  	set_tsk_thread_flag(tsk,TIF_NEED_RESCHED);
> --- linux-2.6.8.1/include/linux/thread_info.h	2004-04-27 20:42:22.000000000 +0200
> +++ linux-m68k-2.6.8.1/include/linux/thread_info.h	2004-09-04 21:24:36.000000000 +0200
> @@ -21,6 +21,7 @@ extern long do_no_restart_syscall(struct
>  #include <asm/thread_info.h>
> 
>  #ifdef __KERNEL__
> +#ifndef __HAVE_THREAD_FUNCTIONS
> 
>  /*
>   * flag set/clear/test wrappers
> @@ -77,16 +78,11 @@ static inline int test_ti_thread_flag(st
>  	return test_bit(flag,&ti->flags);
>  }
> 
> -static inline void set_need_resched(void)
> -{
> -	set_thread_flag(TIF_NEED_RESCHED);
> -}
> +#endif	/* __HAVE_THREAD_FUNCTIONS */
> 
> -static inline void clear_need_resched(void)
> -{
> -	clear_thread_flag(TIF_NEED_RESCHED);
> -}
> +#define set_need_resched() set_thread_flag(TIF_NEED_RESCHED)
> +#define clear_need_resched(void) clear_thread_flag(TIF_NEED_RESCHED)
> 
> -#endif
> +#endif	/* __KERNEL__ */
> 
>  #endif /* _LINUX_THREAD_INFO_H */
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> [*] For reference:
> 
>     http://linux-m68k-cvs.ubb.ca/~geert/linux-m68k-2.6.x-merging/POSTPONED/156-thread_info.diff
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
---end quoted text---

Re: Getting kernel.org kernel to build for m68k?

[Matthias Urlichs]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

Hi,

Christoph Hellwig:
> > Hence if no one objects, I'll submit the patch to Andrew and Linus.
> 
> the common code changes below are not okay.

Why not?

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Getting kernel.org kernel to build for m68k?

[Christoph Hellwig]

On Sun, Sep 05, 2004 at 03:19:48PM +0200, Matthias Urlichs wrote:
> Hi,
> 
> Christoph Hellwig:
> > > Hence if no one objects, I'll submit the patch to Andrew and Linus.
> > 
> > the common code changes below are not okay.
> 
> Why not?

Because we don't want gazillions of special cases in common code.  We
already added support for allocating the thread_info and task_struct
as a single object because ia64 needed it, there's no reason to stack
another hack ontop for m68k.

Re: Getting kernel.org kernel to build for m68k?

[Roman Zippel]

Hi,

On Sun, 5 Sep 2004, Christoph Hellwig wrote:

> Because we don't want gazillions of special cases in common code.  We
> already added support for allocating the thread_info and task_struct
> as a single object because ia64 needed it, there's no reason to stack
> another hack ontop for m68k.

What ia64 is doing is already a hack and doesn't really apply to m68k, as 
we want to keep the stack separate.
The basic problem is something completely different, as soon as an arch 
wants to reorganize some data structures a bit different you are in 
include hell. The problem are the mixture of structure definitions and 
inline functions, as soon as inline functions use functions/structures not 
defined in the same file, the include dependencies become very fragile.
So we either have the choice we only use macros or we separate some core 
data types into their own headers (well, the only other option is that 
m68k has to stack more hacks on the ia64 hack).
So as soon as one wants to allocate thread_info and task_struct together 
without using hacks, one very populuar problem are the various lock 
functions and their use of preempt_enable(), which needs access to 
thread_info, but sched.h (and so task_struct) needs the definition of 
various data structures. The spinlock functions are all still macros, but 
a lot of other lock functions, which were added after the stack/ 
task_struct split, are real inline functions and make a reorganization 
very painful.

bye, Roman

Re: Getting kernel.org kernel to build for m68k?

[Matthias Urlichs]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

Hi,

Christoph Hellwig:
> > Why not?
> 
> Because we don't want gazillions of special cases in common code.  We
> already added support for allocating the thread_info and task_struct
> as a single object because ia64 needed it, there's no reason to stack
> another hack ontop for m68k.

OK -- I'll investigate changing that. It'll be a few days until I can get
to it however :-/  so if anybody beats me to it, fine.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]