lkml.org 
[lkml]   [2008]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] add the clone64() and unshare64() syscalls
sukadev@us.ibm.com wrote:
> Jakub Jelinek [jakub@redhat.com] wrote:
> | On Wed, Apr 09, 2008 at 03:34:59PM -0700, sukadev@us.ibm.com wrote:
> | > From: Cedric Le Goater <clg@fr.ibm.com>
> | > Subject: [PATCH 3/3] add the clone64() and unshare64() syscalls
> | >
> | > This patch adds 2 new syscalls :
> | >
> | > long sys_clone64(unsigned long flags_high, unsigned long flags_low,
> | > unsigned long newsp);
> | >
> | > long sys_unshare64(unsigned long flags_high, unsigned long flags_low);
> |
> | Can you explain why are you adding it for 64-bit arches too? unsigned long
> | is there already 64-bit, and both sys_clone and sys_unshare have unsigned
> | long flags, rather than unsigned int.
>
> Hmm,
>
> By simply resuing clone() on 64 bit and adding a new call for 32-bit won't
> the semantics of clone() differ between the two ?
>
> i.e clone() on 64 bit supports say CLONE_NEWPTS clone() on 32bit does not ?
>
> Wouldn't it be simpler/cleaner if clone() and clone64() behaved the same
> on both 32 and 64 bit systems ?
>

No, not really. The way this work on the libc side is pretty much "use
clone64 if it exists, otherwise use clone".

-hpa


\
 
 \ /
  Last update: 2008-04-10 05:47    [W:0.061 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site