[Linux-ia64] kernel 2.5.69 doesn't compile for UP

[Linux-ia64] kernel 2.5.69 doesn't compile for UP

[Eric Piel]

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

Hello,
There is a compile error if not compiling for SMP:

  gcc -Wp,-MD,arch/ia64/kernel/.mca.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -g -O2 -fno-strict-aliasing
-fno-common -pipe  -ffixed-r13 -mfixed-range=f10-f15,f32-f127
-falign-functions=32 -fomit-frame-pointer -nostdinc -iwithprefix include
-mconstant-gp   -DKBUILD_BASENAME=mca -DKBUILD_MODNAME=mca -c -o
arch/ia64/kernel/mca.o arch/ia64/kernel/mca.c
arch/ia64/kernel/mca.c: In function `init_handler_platform':
arch/ia64/kernel/mca.c:347: structure has no member named `write_lock'
arch/ia64/kernel/mca.c:359: structure has no member named `write_lock'
make[1]: *** [arch/ia64/kernel/mca.o] Error 1
make: *** [arch/ia64/kernel] Error 2

It's a bit obvious, in UP tasklist_lock doesn't contain any member :-(
The attached patch let the compilation go. However I don't think it
looks good, there is probably a cleaner way to solve this problem but my
knowledge about the locks is really too little...

Eric

[-- Attachment #2: UP-fix-2.5.69-030514.patch --]
[-- Type: text/plain, Size: 642 bytes --]

--- linux-2.5.69-ia64-perfmon/arch/ia64/kernel/mca.c	2003-05-12 13:21:54.000000000 +0200
+++ linux-2.5.69-ia64-030509.orig/arch/ia64/kernel/mca.c	2003-05-14 14:16:48.000000000 +0200
@@ -344,7 +344,9 @@
 	unw_init_from_interruption(&info, current, pt, sw);
 	ia64_do_show_stack(&info, NULL);
 
+#ifdef CONFIG_SMP
 	if (!tasklist_lock.write_lock)
+#endif
 		read_lock(&tasklist_lock);
 	{
 		struct task_struct *g, *t;
@@ -356,7 +358,9 @@
 			show_stack(t);
 		} while_each_thread (g, t);
 	}
+#ifdef CONFIG_SMP
 	if (!tasklist_lock.write_lock)
+#endif
 		read_unlock(&tasklist_lock);
 
 	printk("\nINIT dump complete.  Please reboot now.\n");

Re: [Linux-ia64] kernel 2.5.69 doesn't compile for UP

[Matthew Wilcox]

On Wed, May 14, 2003 at 03:31:08PM +0200, Eric Piel wrote:
> Hello,
> There is a compile error if not compiling for SMP:

> +#ifdef CONFIG_SMP
>  	if (!tasklist_lock.write_lock)
> +#endif
>  		read_lock(&tasklist_lock);

Yuck.  The right way to do this is read_trylock(&tasklist_lock);
The observant will have noted:

#define write_trylock(lock)     ({preempt_disable();_raw_write_trylock(lock) ? \
                                1 : ({preempt_enable(); 0;});})

/* Where's read_trylock? */

in include/linux/spinlock.h but that doen't justify _not writing it_
when you need it.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [Linux-ia64] kernel 2.5.69 doesn't compile for UP

[David Mosberger]

>>>>> On Wed, 14 May 2003 15:16:49 +0100, Matthew Wilcox <willy@debian.org> said:

  Matthew> On Wed, May 14, 2003 at 03:31:08PM +0200, Eric Piel wrote:
  >> Hello, There is a compile error if not compiling for SMP:

  >> +#ifdef CONFIG_SMP if (!tasklist_lock.write_lock) +#endif
  >> read_lock(&tasklist_lock);

  Matthew> Yuck.  The right way to do this is
  Matthew> read_trylock(&tasklist_lock); The observant will have
  Matthew> noted:

  Matthew> /* Where's read_trylock? */

  Matthew> in include/linux/spinlock.h but that doen't justify _not
  Matthew> writing it_ when you need it.

You want to send me a patch? ;-)

	--david

Re: [Linux-ia64] kernel 2.5.69 doesn't compile for UP

[Matthew Wilcox]

On Wed, May 14, 2003 at 10:32:14AM -0700, David Mosberger wrote:
>   Matthew> Yuck.  The right way to do this is
>   Matthew> read_trylock(&tasklist_lock); The observant will have
>   Matthew> noted:
> 
>   Matthew> /* Where's read_trylock? */
> 
>   Matthew> in include/linux/spinlock.h but that doen't justify _not
>   Matthew> writing it_ when you need it.
> 
> You want to send me a patch? ;-)

Yes, I'd love to ;-)  I just need to fix your 2.5.69 patch so it'll compile :-P
$ find -type f |xargs grep compat_sys_setaffinity
./arch/ia64/ia32/ia32_entry.S:  data8 compat_sys_setaffinity
Binary file ./arch/ia64/ia32/ia32_entry.o matches
Binary file ./arch/ia64/ia32/built-in.o matches


Seriously, this is an attitude I see way too much of in this port.
Something's broken so it gets kludged inside arch/ia64 (or worse yet,
inside arch/ia64/sn/kernel/sn2/...) rather than fixing it properly.
Maybe it's a relic of the "secret beginnings" of this port, or maybe
people from certain companies have too narrow a focus, but it has to stop.
I think the attitude is starting to change but there's a lot of cruft
built up.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [Linux-ia64] kernel 2.5.69 doesn't compile for UP

[Andreas Schwab]

Matthew Wilcox <willy@debian.org> writes:

|> On Wed, May 14, 2003 at 10:32:14AM -0700, David Mosberger wrote:
|> >   Matthew> Yuck.  The right way to do this is
|> >   Matthew> read_trylock(&tasklist_lock); The observant will have
|> >   Matthew> noted:
|> > 
|> >   Matthew> /* Where's read_trylock? */
|> > 
|> >   Matthew> in include/linux/spinlock.h but that doen't justify _not
|> >   Matthew> writing it_ when you need it.
|> > 
|> > You want to send me a patch? ;-)
|> 
|> Yes, I'd love to ;-)  I just need to fix your 2.5.69 patch so it'll compile :-P
|> $ find -type f |xargs grep compat_sys_setaffinity
|> ./arch/ia64/ia32/ia32_entry.S:  data8 compat_sys_setaffinity
|> Binary file ./arch/ia64/ia32/ia32_entry.o matches
|> Binary file ./arch/ia64/ia32/built-in.o matches

--- linux-2.5.69/arch/ia64/ia32/ia32_entry.S.~1~	2003-05-14 12:14:33.000000000 +0200
+++ linux-2.5.69/arch/ia64/ia32/ia32_entry.S	2003-05-14 12:57:22.000000000 +0200
@@ -439,8 +439,8 @@ ia32_syscall_table:
 	data8 sys_ni_syscall
 	data8 sys_ni_syscall
 	data8 compat_sys_futex	/* 240 */
-	data8 compat_sys_setaffinity
-	data8 compat_sys_getaffinity
+	data8 compat_sys_sched_setaffinity
+	data8 compat_sys_sched_getaffinity
 	data8 sys_ni_syscall
 	data8 sys_ni_syscall
 	data8 sys_ni_syscall	/* 245 */

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Linux-ia64] kernel 2.5.69 doesn't compile for UP

[David Mosberger]

>>>>> On Wed, 14 May 2003 19:05:45 +0100, Matthew Wilcox <willy@debian.org> said:

  Matthew> Yes, I'd love to ;-) I just need to fix your 2.5.69 patch
  Matthew> so it'll compile :-P $ find -type f |xargs grep
  Matthew> compat_sys_setaffinity ./arch/ia64/ia32/ia32_entry.S: data8

The ia32 subsystem does NOT work at the moment, as I mentioned in my
announcement.  If you chose to ignore my messages, tough luck.

  Matthew> Seriously, this is an attitude I see way too much of in
  Matthew> this port.  Something's broken so it gets kludged inside
  Matthew> arch/ia64 (or worse yet,

It's always nice to hear your opinions.

  Matthew> Maybe it's a relic of the "secret beginnings" of this port,
  Matthew> or maybe people from certain companies have too narrow a
  Matthew> focus, but it has to stop.  I think the attitude is
  Matthew> starting to change but there's a lot of cruft built up.

Oh, yeah, bring out your conspiracy theories.  Yawn.

Perhaps you might want to consider a more obvious scenario?  Like,
there is much more work to go around than time/people to do it all and
hence certain things get lower priority?

In fact, why not start with yourself?  If you see something that you
absolutely hate, send in a patch to fix it.  That's how Linux works.

	--david

Re: [Linux-ia64] kernel 2.5.69 doesn't compile for UP

[David Mosberger]

>>>>> On Wed, 14 May 2003 20:55:56 +0200, Andreas Schwab <schwab@suse.de> said:

  Andreas> -	data8 compat_sys_setaffinity
  Andreas> -	data8 compat_sys_getaffinity
  Andreas> +	data8 compat_sys_sched_setaffinity
  Andreas> +	data8 compat_sys_sched_getaffinity

I applied this patch.

Thanks!

	--david