PRIVATE...

I have a business Proposal that will be of benefit to the both of us.Kindly contact me on mrmichealwu...@yahoo.com.hk should this be of interest to you.

PRIVATE...

I have a business Proposal that will be of benefit to the both of us.Kindly contact me on mrmichealwu...@yahoo.com.hk should this be of interest to you.

Private Investition

-- Diese E-Mail fordert Sie strikt auf, sich für eine große Investition mit mir zusammenzutun, um weitere Informationen zu erhalten. Mit freundlichen Grüßen, Khvostova Zhanna -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.ker

Private Message!!

details. I will prefer you to reach me on my private Email address below: Email: leecheun...@yahoo.com.hk Kind Regards, Mr. Lee Cheung. -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo inf

It is Utterly Private

It is Private I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other better

Re: Add private syscalls to support NPTL

On 12/11/09 7:23 PM, Maxim Kuvyrkov wrote: On 12/11/09 5:01 PM, Geert Uytterhoeven wrote: On Mon, Dec 7, 2009 at 09:38, Maxim Kuvyrkov wrote: ... BTW, 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

Re: Add private syscalls to support NPTL

On 12/11/09 5:01 PM, Geert Uytterhoeven wrote: On Mon, Dec 7, 2009 at 09:38, Maxim Kuvyrkov 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

Re: Add private syscalls to support NPTL

On Mon, Dec 7, 2009 at 09:38, Maxim Kuvyrkov wrote: > Maxim Kuvyrkov wrote: >> The attached patches add kernel support for userspace NPTL bits for m68k. > > Here is yet another final version of the patch.  As Andreas pointed out in > another thread, the indentation is off in couple of places, so I

Re: Add private syscalls to support NPTL

On 12/9/09 6:44 PM, Klaus Kuehnhammer wrote: Hello again, It looks like the issue is caused by the page being write-protected. Adding !pte_write(*pte) to the checks seems to fix this, it goes into page fault and reloads the page entry writable. A patch is attached. I'm not entirely comfortable

Re: Add private syscalls to support NPTL

Hello again, It looks like the issue is caused by the page being write-protected. Adding !pte_write(*pte) to the checks seems to fix this, it goes into page fault and reloads the page entry writable. A patch is attached. I'm not entirely comfortable w/this solution... I understand why calling

Re: Add private syscalls to support NPTL

Klaus Kuehnhammer wrote: Hi! I've been testing this patch (together w/the latest codesourcery toolchain release) on an m548x the last couple of days. It looks like there is still an issue in sys_atomic_cmpxchg_32. When cloning a large process, it accesses memory it shouldn't: Hi Klaus, Whi

Re: Add private syscalls to support NPTL

Hi! I've been testing this patch (together w/the latest codesourcery toolchain release) on an m548x the last couple of days. It looks like there is still an issue in sys_atomic_cmpxchg_32. When cloning a large process, it accesses memory it shouldn't: cmpxchg32: new 1, old 0, mem 801cb604 cmp

Re: Add private syscalls to support NPTL

Maxim Kuvyrkov wrote: Hello Geert, The attached patches add kernel support for userspace NPTL bits for m68k. Here is yet another final version of the patch. As Andreas pointed out in another thread, the indentation is off in couple of places, so I fixed that by formatting the code with scri

Re: Add private syscalls to support NPTL

On Tue, 10 Nov 2009, Maxim Kuvyrkov wrote: > Finn Thain wrote: > > > > > Do you think my patch is a reasonable solution? I don't understand it, I > > just copied it from x86 -- "monkey see, monkey do." > > I can't spot anything wrong in it. Thanks for looking it over. I'll send it upstream.

Re: Add private syscalls to support NPTL

Finn Thain wrote: On Fri, 6 Nov 2009, Maxim Kuvyrkov wrote: Finn Thain wrote: On Wed, 28 Oct 2009, Maxim Kuvyrkov wrote: ... We [CodeSourcery] have just updated all of our toolchains, and the GNU/Linux toolchain is based on EGLIBC 2.10 and has well tested TLS/NPTL support. If you are ta

Re: Add private syscalls to support NPTL

On Tue, Nov 10, 2009 at 03:07:28PM +1100, Finn Thain wrote: > I also tried eglibc trunk but the build failed elsewhere: > > ../sysdeps/unix/sysv/linux/i386/fcntl.c: In function '__fcntl_nocancel': > ../sysdeps/unix/sysv/linux/i386/fcntl.c:133: error: storage size of 'fex' > isn't known > ../sysde

Re: Add private syscalls to support NPTL

On Fri, 6 Nov 2009, Maxim Kuvyrkov wrote: > Finn Thain wrote: > > On Wed, 28 Oct 2009, Maxim Kuvyrkov wrote: > > > > > ... > > > > > > We [CodeSourcery] have just updated all of our toolchains, and the > > > GNU/Linux toolchain is based on EGLIBC 2.10 and has well tested > > > TLS/NPTL suppo

Re: Add private syscalls to support NPTL

Finn Thain wrote: On Wed, 28 Oct 2009, Maxim Kuvyrkov wrote: ... We [CodeSourcery] have just updated all of our toolchains, and the GNU/Linux toolchain is based on EGLIBC 2.10 and has well tested TLS/NPTL support. If you are targeting ColdFire you can simply download the toolchain at

Re: Add private syscalls to support NPTL

On Wed, 28 Oct 2009, Maxim Kuvyrkov wrote: >... > > We [CodeSourcery] have just updated all of our toolchains, and the > GNU/Linux toolchain is based on EGLIBC 2.10 and has well tested TLS/NPTL > support. If you are targeting ColdFire you can simply download the > toolchain at

Re: Add private syscalls to support NPTL

On Wed, 28 Oct 2009, Maxim Kuvyrkov wrote: > Finn Thain wrote: > > > > On Mon, 26 Oct 2009, Maxim Kuvyrkov wrote: > > > > > Maxim Kuvyrkov wrote: > > > ... > > > > Geert, in case there'll be further changes in the NPTL patch, > > > > would you like me submit full patch against original tree o

Re: Add private syscalls to support NPTL

Finn Thain wrote: On Mon, 26 Oct 2009, Maxim Kuvyrkov wrote: Maxim Kuvyrkov wrote: ... Geert, in case there'll be further changes in the NPTL patch, would you like me submit full patch against original tree or only the incremental difference? Ping. Geert, did you have a chance to look over

Re: Add private syscalls to support NPTL

On Mon, 26 Oct 2009, Maxim Kuvyrkov wrote: > Maxim Kuvyrkov wrote: > ... > > Geert, in case there'll be further changes in the NPTL patch, would > > you like me submit full patch against original tree or only the > > incremental difference? > > Ping. > > Geert, did you have a chance to look

Re: Add private syscalls to support NPTL

Maxim Kuvyrkov wrote: ... Geert, in case there'll be further changes in the NPTL patch, would you like me submit full patch against original tree or only the incremental difference? Ping. Geert, did you have a chance to look over the patch from Oct. 2 2009? I've done a lot of testing since t

Re: Add private syscalls to support NPTL

Maxim Kuvyrkov wrote: Maxim Kuvyrkov wrote: Maxim Kuvyrkov wrote: Here is the updated patch. Hm, I've attached the patch without the unistd.h hunk. Here is the proper one. Yet, another update patch. This version fixes several indentation errors. BTW, Geert, what is the preferred branch

Re: Add private syscalls to support NPTL

Maxim Kuvyrkov wrote: Maxim Kuvyrkov wrote: Here is the updated patch. Hm, I've attached the patch without the unistd.h hunk. Here is the proper one. Yet, another update patch. This version fixes several indentation errors. BTW, Geert, what is the preferred branch in m68k git repository

Re: Add private syscalls to support NPTL

+0400 Subject: [PATCH] Add syscalls to support m68k NPTL. This patch adds several syscalls, private to M68K, that provide necessary functionality to support NPTL. The syscalls are read_tp, write_tp, atomic_cmpxchg_32 and atomic_barrier. The cmpxchg syscall is required for ColdFire as it doesn't su

Re: Add private syscalls to support NPTL

, -- Maxim K. CodeSourcery From 2e11b258c406cd5cd71b82c39066d9dc35010891 Mon Sep 17 00:00:00 2001 From: Maxim Kuvyrkov Date: Mon, 24 Aug 2009 00:10:33 +0400 Subject: [PATCH] Add syscalls to support m68k NPTL. This patch adds several syscalls, private to M68K, that provide necessary functionality to

Re: Add private syscalls to support NPTL

Brad Boyer writes: > On Tue, Aug 18, 2009 at 11:07:26AM +0400, Maxim Kuvyrkov wrote: >> The reason for this calling convention is to minimize difference in >> invokation of the vDSO helper and the syscall. The helper gets its >> arguments in a0 (mem), d0 (oldval) and d1 (newval); in a stub, wh

Re: Add private syscalls to support NPTL

Brad Boyer wrote: On Tue, Aug 18, 2009 at 11:07:26AM +0400, Maxim Kuvyrkov wrote: Brad Boyer wrote: On Tue, Aug 18, 2009 at 01:48:39AM +0400, Maxim Kuvyrkov wrote: +/* This syscall gets its arguments in A0 (mem), A1 (oldval) and + D1 (newval). */ +asmlinkage int +m68k_sys_atomic_cmpxchg_32(

Re: Add private syscalls to support NPTL

On Tue, Aug 18, 2009 at 11:07:26AM +0400, Maxim Kuvyrkov wrote: > Brad Boyer wrote: > >On Tue, Aug 18, 2009 at 01:48:39AM +0400, Maxim Kuvyrkov wrote: > >>+/* This syscall gets its arguments in A0 (mem), A1 (oldval) and > >>+ D1 (newval). */ > >>+asmlinkage int > >>+m68k_sys_atomic_cmpxchg_32(un

Re: Add private syscalls to support NPTL

Geert Uytterhoeven writes: > Probably I should wire those up first (for 2.6.31, if still possible). > > Next I should reserve 333..336 for you? We could even (re-)use some of the smaller numbers that were never implemented, allowing the use of moveq. Andreas. -- Andreas Schwab, sch...@linux-m

Re: Add private syscalls to support NPTL

Geert Uytterhoeven wrote: On Tue, Aug 18, 2009 at 10:56, Maxim Kuvyrkov wrote: Andreas Schwab wrote: Maxim Kuvyrkov writes: The need would be (a) use numbers that are very unlikely to used for normal syscalls, I don't understand. These are normal syscalls. and (b) using -1..-4 for the sys

Re: Add private syscalls to support NPTL

On Tue, Aug 18, 2009 at 10:56, Maxim Kuvyrkov wrote: > Andreas Schwab wrote: >> Maxim Kuvyrkov writes: >>> The need would be (a) use numbers that are very unlikely to used for >>> normal syscalls, >> >> I don't understand.  These are normal syscalls. >> >>> and (b) using -1..-4 for the syscall num

Re: Add private syscalls to support NPTL

Andreas Schwab wrote: Maxim Kuvyrkov writes: The need would be (a) use numbers that are very unlikely to used for normal syscalls, I don't understand. These are normal syscalls. and (b) using -1..-4 for the syscall numbers works out quite nicely for the code in entry.S. It adds just a co

Re: Add private syscalls to support NPTL

Maxim Kuvyrkov writes: > The need would be (a) use numbers that are very unlikely to used for > normal syscalls, I don't understand. These are normal syscalls. > and (b) using -1..-4 for the syscall numbers works out quite nicely > for the code in entry.S. It adds just a couple of instruction

Re: Add private syscalls to support NPTL

__NR_pwritev 330 +/* Private syscalls. */ +#define __M68K_NR_read_tp 0x +#define __M68K_NR_write_tp 0xfffe +#define __M68K_NR_atomic_cmpxchg_320xfffd +#define __M68K_NR_atomic_barrier 0xfffc I don't see the need for these

Re: Add private syscalls to support NPTL

Andreas Schwab wrote: Maxim Kuvyrkov writes: + { + int do_page_fault(struct pt_regs *, unsigned long, + unsigned long); Functions should always be declared in headers, and definitely never in block scope. I missed th

Re: Add private syscalls to support NPTL

Brad Boyer wrote: On Tue, Aug 18, 2009 at 01:48:39AM +0400, Maxim Kuvyrkov wrote: +/* This syscall gets its arguments in A0 (mem), A1 (oldval) and + D1 (newval). */ +asmlinkage int +m68k_sys_atomic_cmpxchg_32(unsigned long newval, int d2, int d3, int d4, int d5, + unsig

Re: Add private syscalls to support NPTL

On Tue, Aug 18, 2009 at 01:48:39AM +0400, Maxim Kuvyrkov wrote: > +/* This syscall gets its arguments in A0 (mem), A1 (oldval) and > + D1 (newval). */ > +asmlinkage int > +m68k_sys_atomic_cmpxchg_32(unsigned long newval, int d2, int d3, int d4, int > d5, > + unsigned long __

Re: Add private syscalls to support NPTL

Maxim Kuvyrkov writes: > + { > + int do_page_fault(struct pt_regs *, unsigned long, > + unsigned long); Functions should always be declared in headers, and definitely never in block scope. Andreas. -- Andreas Schwab, sch...@l

Re: Add private syscalls to support NPTL

#define __NR_pwritev 330 > > +/* Private syscalls. */ > +#define __M68K_NR_read_tp0x > +#define __M68K_NR_write_tp 0xfffe > +#define __M68K_NR_atomic_cmpxchg_32 0xfffd > +#define __M68K_NR_atomic_barrier 0xfffc I don't

Add private syscalls to support NPTL

ls to support m68k NPTL. This patch adds several syscalls, private to M68K, that provide necessary functionality to support NPTL. The syscalls are read_tp, write_tp, atomic_cmpxchg_32 and atomic_barrier. The cmpxchg syscall is required for ColdFire as it doesn't support 'cas' ins