On 12/11/09 5:01 PM, Geert Uytterhoeven wrote:
On Mon, Dec 7, 2009 at 09:38, Maxim Kuvyrkov<maxim@xxxxxxxxxxxxxxxx> wrote:
...
diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h index 48b87f5..d076bea 100644 --- a/arch/m68k/include/asm/unistd.h +++ b/arch/m68k/include/asm/unistd.h @@ -336,10 +336,14 @@ #define __NR_pwritev 330 #define __NR_rt_tgsigqueueinfo 331 #define __NR_perf_event_open 332 +#define __NR_read_tp 333 +#define __NR_write_tp 334 +#define __NR_atomic_cmpxchg_32 335 +#define __NR_atomic_barrier 336BTW, other architectures seem to call these __NR_[gs]et_thread_area instead of __NR_{read,write}_tp? Shouldn't we follow for consistency?
Yes, we may. As long as the syscall numbers stay the same. I'll send the updated patch once the memory handling issue is resolved.
BTW, does the analysis of the memory handling bug (http://marc.info/?l=linux-m68k&m=126043678613032&w=2) look right to you?
Regards, -- Maxim Kuvyrkov CodeSourcery maxim@xxxxxxxxxxxxxxxx (650) 331-3385 x724 -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
