From macro@ds2.pg.gda.pl Mon Jun 3 18:46:00 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA25897; Mon, 3 Jun 2002 18:46:00 +0200 (MET DST) Received-Date: Mon, 3 Jun 2002 18:46:00 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd025895; Mon Jun 3 18:45:50 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA19600; Mon, 3 Jun 2002 18:45:51 +0200 (MET DST) Date: Mon, 3 Jun 2002 18:45:49 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: mb() and friends again Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, There was a discussion some time ago upon my proposal of a clean-up of mb() and related macros. The conclusion was a rewrite is desireable, but the patch wasn't accepted and no alternative was proposed. The need for the update is more and more crucial for me as I have more and more code to apply to the tree that needs the macros be set somehow. If there is a design flaw, I'd like to know of it, if there is an implementation problem, I'm willing to fix it. I'm aware about peripheral bus-specific coherency problems -- the patch is orthogonal to them and only addresses the host bus. Here is an updated version I'm using currently. It's fixed to apply against the current tree and adds for source code compatibility. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.18-20020530-mb-wb-8 diff -up --recursive --new-file linux-mips-2.4.18-20020530.macro/arch/mips/config.in linux-mips-2.4.18-20020530/arch/mips/config.in --- linux-mips-2.4.18-20020530.macro/arch/mips/config.in 2002-05-30 02:57:35.000000000 +0000 +++ linux-mips-2.4.18-20020530/arch/mips/config.in 2002-06-02 15:51:03.000000000 +0000 @@ -393,6 +393,11 @@ else fi fi fi +if [ "$CONFIG_CPU_R3000" = "y" ]; then + define_bool CONFIG_CPU_HAS_SYNC n +else + define_bool CONFIG_CPU_HAS_SYNC y +fi endmenu mainmenu_option next_comment diff -up --recursive --new-file linux-mips-2.4.18-20020530.macro/include/asm-mips/system.h linux-mips-2.4.18-20020530/include/asm-mips/system.h --- linux-mips-2.4.18-20020530.macro/include/asm-mips/system.h 2002-05-28 10:13:21.000000000 +0000 +++ linux-mips-2.4.18-20020530/include/asm-mips/system.h 2002-06-02 15:51:03.000000000 +0000 @@ -18,9 +18,12 @@ #include #include -#include + #include +#include +#include + __asm__ ( ".macro\t__sti\n\t" ".set\tpush\n\t" @@ -166,32 +169,58 @@ extern void __global_restore_flags(unsig #define local_irq_disable() __cli() #define local_irq_enable() __sti() -/* - * These are probably defined overly paranoid ... - */ +#ifdef CONFIG_CPU_HAS_SYNC +#define __sync() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + ".set mips2\n\t" \ + "sync\n\t" \ + ".set pop" \ + : /* no output */ \ + : /* no input */ \ + : "memory") +#else +#define __sync() do { } while(0) +#endif + +#define __fast_iob() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "lw $0,%0\n\t" \ + "nop\n\t" \ + ".set pop" \ + : /* no output */ \ + : "m" (*(int *)KSEG1) \ + : "memory") + +#define fast_wmb() __sync() +#define fast_rmb() __sync() +#define fast_mb() __sync() +#define fast_iob() \ + do { \ + __sync(); \ + __fast_iob(); \ + } while (0) + #ifdef CONFIG_CPU_HAS_WB #include -#define rmb() do { } while(0) -#define wmb() wbflush() -#define mb() wbflush() - -#else /* CONFIG_CPU_HAS_WB */ - -#define mb() \ -__asm__ __volatile__( \ - "# prevent instructions being moved around\n\t" \ - ".set\tnoreorder\n\t" \ - "# 8 nops to fool the R4400 pipeline\n\t" \ - "nop;nop;nop;nop;nop;nop;nop;nop\n\t" \ - ".set\treorder" \ - : /* no output */ \ - : /* no input */ \ - : "memory") -#define rmb() mb() -#define wmb() mb() -#endif /* CONFIG_CPU_HAS_WB */ +#define wmb() fast_wmb() +#define rmb() fast_rmb() +#define mb() wbflush(); +#define iob() wbflush(); + +#else /* !CONFIG_CPU_HAS_WB */ + +#define wmb() fast_wmb() +#define rmb() fast_rmb() +#define mb() fast_mb() +#define iob() fast_iob() + +#endif /* !CONFIG_CPU_HAS_WB */ #ifdef CONFIG_SMP #define smp_mb() mb() diff -up --recursive --new-file linux-mips-2.4.18-20020530.macro/include/asm-mips/wbflush.h linux-mips-2.4.18-20020530/include/asm-mips/wbflush.h --- linux-mips-2.4.18-20020530.macro/include/asm-mips/wbflush.h 2001-09-07 04:26:33.000000000 +0000 +++ linux-mips-2.4.18-20020530/include/asm-mips/wbflush.h 2002-02-04 02:52:11.000000000 +0000 @@ -6,29 +6,30 @@ * for more details. * * Copyright (c) 1998 Harald Koerfgen + * Copyright (C) 2002 Maciej W. Rozycki */ #ifndef __ASM_MIPS_WBFLUSH_H #define __ASM_MIPS_WBFLUSH_H #include -#if defined(CONFIG_CPU_HAS_WB) -/* - * R2000 or R3000 - */ -extern void (*__wbflush) (void); +#ifdef CONFIG_CPU_HAS_WB -#define wbflush() __wbflush() +extern void (*__wbflush)(void); +extern void wbflush_setup(void); -#else -/* - * we don't need no stinkin' wbflush - */ +#define wbflush() \ + do { \ + __sync(); \ + __wbflush(); \ + } while (0) -#define wbflush() do { } while(0) +#else /* !CONFIG_CPU_HAS_WB */ -#endif +#define wbflush_setup() do { } while (0) -extern void wbflush_setup(void); +#define wbflush() fast_iob() + +#endif /* !CONFIG_CPU_HAS_WB */ #endif /* __ASM_MIPS_WBFLUSH_H */ diff -up --recursive --new-file linux-mips-2.4.18-20020530.macro/include/asm-mips64/system.h linux-mips-2.4.18-20020530/include/asm-mips64/system.h --- linux-mips-2.4.18-20020530.macro/include/asm-mips64/system.h 2002-05-28 10:13:22.000000000 +0000 +++ linux-mips-2.4.18-20020530/include/asm-mips64/system.h 2002-06-02 15:55:32.000000000 +0000 @@ -12,9 +12,12 @@ #include #include -#include + #include +#include +#include + __asm__ ( ".macro\t__sti\n\t" ".set\tpush\n\t" @@ -161,20 +164,37 @@ extern void __global_restore_flags(unsig #define local_irq_disable() __cli() #define local_irq_enable() __sti() -/* - * These are probably defined overly paranoid ... - */ -#define mb() \ -__asm__ __volatile__( \ - "# prevent instructions being moved around\n\t" \ - ".set\tnoreorder\n\t" \ - "sync\n\t" \ - ".set\treorder" \ - : /* no output */ \ - : /* no input */ \ - : "memory") -#define rmb() mb() -#define wmb() mb() +#define __sync() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "sync\n\t" \ + ".set pop" \ + : /* no output */ \ + : /* no input */ \ + : "memory") + +#define fast_wmb() __sync() +#define fast_rmb() __sync() +#define fast_mb() __sync() +#define fast_iob() \ + do { \ + __sync(); \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "lw $0,%0\n\t" \ + "nop\n\t" \ + ".set pop" \ + : /* no output */ \ + : "m" (*(int *)KSEG1) \ + : "memory"); \ + } while (0) + +#define wmb() fast_wmb() +#define rmb() fast_rmb() +#define mb() fast_mb() +#define iob() fast_iob() #ifdef CONFIG_SMP #define smp_mb() mb() diff -up --recursive --new-file linux-mips-2.4.18-20020530.macro/include/asm-mips64/wbflush.h linux-mips-2.4.18-20020530/include/asm-mips64/wbflush.h --- linux-mips-2.4.18-20020530.macro/include/asm-mips64/wbflush.h 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips-2.4.18-20020530/include/asm-mips64/wbflush.h 2002-05-31 11:43:50.000000000 +0000 @@ -0,0 +1,18 @@ +/* + * Header file for using the wbflush routine + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (c) 1998 Harald Koerfgen + * Copyright (C) 2002 Maciej W. Rozycki + */ +#ifndef __ASM_MIPS64_WBFLUSH_H +#define __ASM_MIPS64_WBFLUSH_H + +#define wbflush_setup() do { } while (0) + +#define wbflush() fast_iob() + +#endif /* __ASM_MIPS64_WBFLUSH_H */ From raiko@niisi.msk.ru Tue Jun 4 13:43:33 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA06815; Tue, 4 Jun 2002 13:43:33 +0200 (MET DST) Received-Date: Tue, 4 Jun 2002 13:43:33 +0200 (MET DST) Received: from t111.niisi.ras.ru(193.232.173.111) via SMTP by guadalquivir.fnet.fr, id smtpd006813; Tue Jun 4 13:43:24 2002 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA01065; Tue, 4 Jun 2002 15:43:06 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA12041; Tue, 4 Jun 2002 15:36:18 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id PAA25417; Tue, 4 Jun 2002 15:37:41 +0400 (MSK) Message-ID: <3CFCA790.9C698A6D@niisi.msk.ru> Date: Tue, 04 Jun 2002 15:42:08 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: mb() and friends again References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Maciej, In previous version of your patch there was the change in mm/c-r3k.c: static void r3k_dma_cache_wback_inv(unsigned long start, unsigned long size) { - wbflush(); + iob(); r3k_flush_dcache_range(start, start + size); } Why did you drop it? It's definetely required. While you patch operates in unusual terms from hw point of view, it does right thins by stating that external wbs do differ from internal wb. Regards, Gleb. Ah. The patch shall be applied, certainly. From macro@ds2.pg.gda.pl Tue Jun 4 16:52:43 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id QAA12492; Tue, 4 Jun 2002 16:52:43 +0200 (MET DST) Received-Date: Tue, 4 Jun 2002 16:52:43 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd012490; Tue Jun 4 16:52:34 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA18686; Tue, 4 Jun 2002 16:52:36 +0200 (MET DST) Date: Tue, 4 Jun 2002 16:52:36 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: mb() and friends again In-Reply-To: <3CFCA790.9C698A6D@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 4 Jun 2002, Gleb O. Raiko wrote: > In previous version of your patch there was the change in mm/c-r3k.c: > > static void r3k_dma_cache_wback_inv(unsigned long start, unsigned long > size) > { > - wbflush(); > + iob(); > r3k_flush_dcache_range(start, start + size); > } > > Why did you drop it? It's definetely required. Nope, it wasn't dropped. It's included in a different patch, namely "patch-mips-2.4.18-20020412-wbflush-5". The patch depends on the "patch-mips-2.4.18-20020530-mb-wb-8" one, so I am not going to resubmit the former one for discussion here until (unless) we decide on the latter one. > While you patch operates in unusual terms from hw point of view, it does > right thins by stating that external wbs do differ from internal wb. What do you mean by "unusual terms"? The names of the macros? Well, they are based on what's used for other platforms and if treated as abstract names (as they should be) they actually reflect reality. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From raiko@niisi.msk.ru Tue Jun 4 19:44:12 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA18934; Tue, 4 Jun 2002 19:44:12 +0200 (MET DST) Received-Date: Tue, 4 Jun 2002 19:44:12 +0200 (MET DST) Received: from t111.niisi.ras.ru(193.232.173.111) via SMTP by guadalquivir.fnet.fr, id smtpd018932; Tue Jun 4 19:44:00 2002 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id VAA07238; Tue, 4 Jun 2002 21:43:01 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id VAA13814; Tue, 4 Jun 2002 21:38:21 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id VAA07610; Tue, 4 Jun 2002 21:40:15 +0400 (MSK) Message-ID: <3CFCFC79.E846226B@niisi.msk.ru> Date: Tue, 04 Jun 2002 21:44:25 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: mb() and friends again References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit "Maciej W. Rozycki" wrote: > > Why did you drop it? It's definetely required. > > Nope, it wasn't dropped. It's included in a different patch, namely > "patch-mips-2.4.18-20020412-wbflush-5". The patch depends on the > "patch-mips-2.4.18-20020530-mb-wb-8" one, so I am not going to resubmit > the former one for discussion here until (unless) we decide on the latter > one. Don't forget the latter one. :-) > > > While you patch operates in unusual terms from hw point of view, it does > > right thins by stating that external wbs do differ from internal wb. > > What do you mean by "unusual terms"? The names of the macros? Well, > they are based on what's used for other platforms and if treated as > abstract names (as they should be) they actually reflect reality. > Basically, the patch logically allows combination of a CPU with internal write-buffer and an external wb chip. It's impossible if hw designers don't smoke hard. :-) In fact, CONFIG_CPU_HAS_WB means !CONFIG_CPU_HAS_WB, i.e. CPU don't have built-in write-buffer logic and there is an external write-buffer chip somewhere in the box. ("Somewhere" means a place on the path from the local bus to a memory controller.) Then, __fast_iob just flushes internal wb while wbflush flushes an external wb. That's why I call it "unusual terms from hw POV". But, don't reimplement the patch, please. It's OK. Just from software point of view. Regards, Gleb. From raiko@niisi.msk.ru Tue Jun 4 20:08:02 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id UAA22685; Tue, 4 Jun 2002 20:08:02 +0200 (MET DST) Received-Date: Tue, 4 Jun 2002 20:08:02 +0200 (MET DST) Received: from t111.niisi.ras.ru(193.232.173.111) via SMTP by guadalquivir.fnet.fr, id smtpd022683; Tue Jun 4 20:07:52 2002 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id WAA07398; Tue, 4 Jun 2002 22:07:59 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id WAA13933; Tue, 4 Jun 2002 22:03:31 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id WAA07935; Tue, 4 Jun 2002 22:04:08 +0400 (MSK) Message-ID: <3CFD0211.17024F14@niisi.msk.ru> Date: Tue, 04 Jun 2002 22:08:17 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Bug in copy_user Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit There is bug in __copy_user (arch/mips*/lib/memcpy.S). Tested for 2.4.18 kernels, but versions 2.2, 2.4, and 2.5 for both mips and mips64 seems to have similar bug. For kernel 2.4.18 and mips __copy_user returns wrong value if len = 4...7 and dst isn't accessible. Other versions behave almost the same, just borders differ. For example, read(0,NULL,len), len=4...7 getsockopt/ioctl(fd, *GET*, NULL, sizeof(int)) returns success. Fortunately, they don't write to at address 0. The following patch seems to be OK for 2.4.18: less_than_4units: /* * rem = len % NBYTES */ beq rem, len, copy_bytes nop 1: EXC( LOAD t0, 0(src), l_exc) ADD src, src, NBYTES SUB len, len, NBYTES -EXC( STORE t0, 0(dst), s_exc) +EXC( STORE t0, 0(dst), s_exc_p1u) bne rem, len, 1b ADD dst, dst, NBYTES Any comments? Regards, Gleb. From macro@ds2.pg.gda.pl Tue Jun 4 20:55:12 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id UAA27393; Tue, 4 Jun 2002 20:55:12 +0200 (MET DST) Received-Date: Tue, 4 Jun 2002 20:55:12 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd027361; Tue Jun 4 20:55:06 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA25734; Tue, 4 Jun 2002 20:55:20 +0200 (MET DST) Date: Tue, 4 Jun 2002 20:55:20 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: mb() and friends again In-Reply-To: <3CFCFC79.E846226B@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 4 Jun 2002, Gleb O. Raiko wrote: > Basically, the patch logically allows combination of a CPU with internal > write-buffer and an external wb chip. It's impossible if hw designers > don't smoke hard. :-) Well, I believe it might be useful -- if a CPU uses a higher clock for its pipeline and a lower one for its external bus, it might be useful to buffer a few words internally to avoid stalls at two consecutive writes. Then you may have an additional buffer externally to lower the number of stalls on memory or I/O (generally the rest of a system) accesses. Essentially a buffer every time you cross a frequency domains' border, leaving the faster one. You need at least a single-word buffer at each such border anyway if you don't want to stall the whole system for any cycle accessing slower domains. Consider it a complement of a hierarchical cache organization -- I've seen (and actually used) systems with up to three levels of caches. > In fact, CONFIG_CPU_HAS_WB means !CONFIG_CPU_HAS_WB, i.e. CPU don't have > built-in write-buffer logic and there is an external write-buffer chip > somewhere in the box. > ("Somewhere" means a place on the path from the local bus to a memory > controller.) That's a bit awkward possibly, but "has" has a wide meaning and does not necessarily state "contains". It might mean "owns" as well. For R[23]k CPUs the option originally corresponded to external R2020 and R3220 chips (just like floating point units may be external but still be considered a part of a CPU) that were treated as a part of coprocessor 0 (with "bc0f" or "bc0t" instructions testing their state). Besides, who says discrete CPUs are forbidden? ;-) > Then, __fast_iob just flushes internal wb while wbflush flushes an > external wb. Well, that's used by __wbflush internally if it knows there is no external buffer that needs explicit handling (for the DECstation, at least -- other systems might make use of it as well). That's unused in this patch but is needed in the other one -- well, I had to split these patches logically somehow and this one only contains system-independent code. > That's why I call it "unusual terms from hw POV". Hopefully, I clarified the terms a bit. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From kevink@mips.com Tue Jun 18 15:53:24 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA06937; Tue, 18 Jun 2002 15:53:24 +0200 (MET DST) Received-Date: Tue, 18 Jun 2002 15:53:24 +0200 (MET DST) Received: from indus.fnet.fr(192.134.188.133) via SMTP by guadalquivir.fnet.fr, id smtpd006935; Tue Jun 18 15:53:21 2002 Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by indus.fnet.fr (8.11.3nb1/8.11.3/$RCSfile$) with ESMTP id g5IDqgM10148 for ; Tue, 18 Jun 2002 15:52:43 +0200 (CEST) Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id GAA12118; Tue, 18 Jun 2002 06:53:06 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA07442; Tue, 18 Jun 2002 06:53:04 -0700 (PDT) Message-ID: <007601c216d0$6f7f0840$10eca8c0@grendel> From: "Kevin D. Kissell" To: , Subject: Linux and the Sony Playstation 2 Date: Tue, 18 Jun 2002 15:59:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 The Sony PS2 Linux kit has been shipping for nearly a month now, and I'm frankly astonished at how little I've seen on this mailing list about it. For better or for worse, this changes everything for MIPS/Linux. The number of MIPS/Linux users worldwide has just gone up by at least an order of magnitude, and they are on a platform running a 2.2.1-derived kernel and using gcc 2.95.2. It's a perfectly usable platform out of the box, but Carsten has thrown "crashme" at it, and it goes down relatively quickly. People trying to port kaffe and other programs that do double-precision float are blocked because there's no double precision on the R5900, and the Sony kernel lacks the Algorithmics emulator. It's not clear what Sony is going to put into further development, and what they are going to expect the user community to take over from here. There is a group of people trying to take the kernel up to 2.2.20, but I'm not yet sure whether they know what they are doing, and anyway, that box needs to get to 2.4.x ASAP. I respectfully submit that, within a year, any MIPS/Linux source tree that does not support the PS2 will be considered obsolete. And that quite specifically includes the one at oss.sgi.com. I personally would want to approach this in terms of merging the necessary PS2 code into something that could be expressed as a patch over kernel.org's 2.4.19_or_better, and which would be provded as the default MIPS kernel technology by MIPS and SGI servers, and ultimately by kernel.org. Is no one else here working on this? Regards, Kevin K.