Re: fork-the-syscall return semantics

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Sat, Feb 16, 2019 at 20:14:35 -0500, Mouse wrote:

> In fork1(), in kern/kern_fork.c, there is code
> 
>         /*
>          * Return child pid to parent process,
>          * marking us as parent via retval[1].
>          */
>         if (retval != NULL) {
>                 retval[0] = p2->p_pid;
>                 retval[1] = 0;
>         }
> 
> This is very old code; identical code appears as far back as 1.4T,
> quite likely even farther back.  It appears the return semantics of
> fork-the-syscall-trap (and related calls, like __vfork14) are a bit
> odd: the parent returns <child,0> and the child returns <parent,1> (or
> at least so a comment in the SPARC libc wrapper claims; I haven't dug
> enough to find the kernel code where the child's return values are set
> up).  But I see no reason for this, as the libc wrapper immediately
> destroys the first return value in the child.
> 
> Does anyone happen to know why this was done?  So far I haven't found
> any reason to not simply return the abstract return value in retval[0]
> like most other syscalls that return a simple integer value, but for a
> special case like this to have survived this long, I can't help feeling
> there must be _something_ behind it.

I would look at 

  http://mail-index.netbsd.org/source-changes/1995/12/10/msg012114.html

  Modified Files:
          init_main.c 
  Log Message:
  Change the way we test whether or not we're in the child process.

except there seems to be no such commit actually recorded in
init_main.c log :)  Was reverted in the repo, I guess.

The code before that change looks like:

#ifdef cpu_set_init_frame			/* XXX should go away */
	if (rval[1]) {
		/*
		 * Now in process 2.
		 */
		start_pagedaemon(curproc);
	}
#else


Its counterpart is

  http://mail-index.netbsd.org/source-changes/1995/12/10/msg012115.html

  Modified Files:
          kern_fork.c 
  Log Message:
  If __FORK_BRAINDAMAGE, continue stuffing retval[1] for the benefit of main().


Other relevant commits are probably:

  http://mail-index.netbsd.org/source-changes/1995/12/09/0000.html
  http://mail-index.netbsd.org/source-changes/1995/12/09/msg012096.html
  http://mail-index.netbsd.org/source-changes/1995/12/09/msg012098.html


-uwe