Re: [PATCH 3/3] add the clone64() and unshare64() syscalls

["H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>]

sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org wrote:
> Jakub Jelinek [jakub-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org] wrote:
> | On Wed, Apr 09, 2008 at 03:34:59PM -0700, sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org wrote:
> | > From: Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
> | > 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