[Devel] Re: [PATCH 0/3] clone64() and unshare64() system calls

2008-04-10 Thread Cedric Le Goater
H. Peter Anvin wrote: [EMAIL PROTECTED] wrote: This is a resend of the patch set Cedric had sent earlier. I ported the patch set to 2.6.25-rc8-mm1 and tested on x86 and x86_64. --- We have run out of the 32 bits in clone_flags ! This patchset introduces 2 new system calls which support

[Devel] Re: [PATCH 0/3] clone64() and unshare64() system calls

2008-04-10 Thread Cedric Le Goater
H. Peter Anvin wrote: [EMAIL PROTECTED] wrote: If you're going to make it a 64-bit pass it in as a 64-bit number, instead of breaking it into two numbers. Maybe I am missing your point. The glibc interface could take a 64bit parameter, but don't we need to pass 32-bit values into the system

[Devel] Re: [PATCH 0/3] clone64() and unshare64() system calls

2008-04-10 Thread H. Peter Anvin
Cedric Le Goater wrote: OK. I didn't know that. I took sys_llseek() as an example of an interface to follow when coded clone64(). llseek() was the first system call that took a doublewidth argument. It's not the one you want to mimic. -hpa

[Devel] Re: [PATCH 0/3] clone64() and unshare64() system calls

2008-04-10 Thread sukadev
Paul Menage [EMAIL PROTECTED] wrote: | On Wed, Apr 9, 2008 at 7:38 PM, [EMAIL PROTECTED] wrote: | | But as Jon Corbet pointed out in the the thread above, it looked like | adding a new system call has been the traditional way of solving this | in Linux so far and there has been no

[Devel] Re: [PATCH 0/3] clone64() and unshare64() system calls

2008-04-09 Thread H. Peter Anvin
[EMAIL PROTECTED] wrote: This is a resend of the patch set Cedric had sent earlier. I ported the patch set to 2.6.25-rc8-mm1 and tested on x86 and x86_64. --- We have run out of the 32 bits in clone_flags ! This patchset introduces 2 new system calls which support 64bit clone-flags.

[Devel] Re: [PATCH 0/3] clone64() and unshare64() system calls

2008-04-09 Thread sukadev
H. Peter Anvin [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: This is a resend of the patch set Cedric had sent earlier. I ported the patch set to 2.6.25-rc8-mm1 and tested on x86 and x86_64. --- We have run out of the 32 bits in clone_flags ! This patchset introduces 2 new system calls

[Devel] Re: [PATCH 0/3] clone64() and unshare64() system calls

2008-04-09 Thread H. Peter Anvin
[EMAIL PROTECTED] wrote: If you're going to make it a 64-bit pass it in as a 64-bit number, instead of breaking it into two numbers. Maybe I am missing your point. The glibc interface could take a 64bit parameter, but don't we need to pass 32-bit values into the system call on 32 bit

[Devel] Re: [PATCH 0/3] clone64() and unshare64() system calls

2008-04-09 Thread sukadev
H. Peter Anvin [EMAIL PROTECTED] wrote: Yes, this was discussed before in the context of Pavel Emelyanov's patch http://lkml.org/lkml/2008/1/16/109 along with sys_indirect(). While there was no consensus, it looked like adding a new system call was better than open ended interfaces.

[Devel] Re: [PATCH 0/3] clone64() and unshare64() system calls

2008-04-09 Thread Paul Menage
On Wed, Apr 9, 2008 at 7:38 PM, [EMAIL PROTECTED] wrote: But as Jon Corbet pointed out in the the thread above, it looked like adding a new system call has been the traditional way of solving this in Linux so far and there has been no consensus on a newer approach. I thought that the