clone return code

clone return code

[Daniel 'NebuchadnezzaR' Dehennin]

Hello,

Sorry if that question seems idiot but is it normal that clone return
the parent pid in the child ?

Is seems that on other architectures it have the same behavior than
fork: return 0 in the child.

Regards.
-- 
Daniel 'NebuchadnezzaR' Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x2A408F69

Re: clone return code

[David S. Miller]

From: Daniel 'NebuchadnezzaR' Dehennin <sparc@asgardr.info>
Date: Wed, 05 Apr 2006 22:46:45 +0200

> Sorry if that question seems idiot but is it normal that clone return
> the parent pid in the child ?
> 
> Is seems that on other architectures it have the same behavior than
> fork: return 0 in the child.

The system call convention follows that of SunOS on which
the syscall handling was based.  Return "1" in the %o1
register in the child and "0" in the parent, and that's how
the the call sites distinguish the two cases.

GLIBC's fork() and clone() stubs interpret this properly and
give the expected return values.

If you want to implement your own direct calls to these
system calls you'll need to handle the return values
properly, else just call the glibc provided stubs directly
which will do this for you.

Why is this an issue?

Re: clone return code

[Daniel 'NebuchadnezzaR' Dehennin]

Le 4599 Septembre 1993, David S. Miller a tapoté:
> The system call convention follows that of SunOS on which
> the syscall handling was based.  Return "1" in the %o1
> register in the child and "0" in the parent, and that's how
> the the call sites distinguish the two cases.

It's what I understand from arch/sparc64/kernel/process.c

> Why is this an issue?

It's not an issue anymore ;-) this behavior is handle now.

Thanks a lot.
-- 
Daniel 'NebuchadnezzaR' Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x2A408F69