Re: [9fans] rfork(), getss() etc etc

[Alexander Viro <viro@math.psu.edu>]

On Sat, 2 Sep 2000, I wrote:

> On Sat, 2 Sep 2000 nigel@9fs.org wrote:
> 
> > Now, what is the problem with this? Firslty, the only way to tell whether
> > you are parent or child after the split is to check the return result from
> > the system call. The inevitable conclusion is that assembly code is
> > required to establish a new stack. This is a retrograde step, and I am
> 
> 	Simply not true. Kernel is perfectly able to set the usermode ESP
> before returning to userland. Code that does transition from the kernel
> mode to user mode is in the kernel. Usually it's an assembler (check
> forkret() in /sys/src/9/pc/l.s for exact parallel). Picking the right ESP
> value happens in IRETL, same way on all systems in question. Nothing
> special in userland.

	Damn. Sorry, I've realized what you might mean right after sending
the reply ;-/ Yes, there is some userland trickery. Unlike other system
calls this beast does essentially

	register (int *)fn(void*) = _fn;
	register void *arg = _arg;
	register unsigned flagd = _flags;
	register int pid;

	/* new_sp ignored unless flags has CLONE_VM set */
	pid = _syscall2(__NR_CLONE, flags, new_sp);
	if ((flags & CLONE_VM) && pid == 0)
		exit((*fn)(arg));
	return pid;

with some gcc-isms to _force_ these variables to be in registers.

Since the thing is in the library _and_ contains the assembler anyway (as
any other system call wrapper, be it on Linux, Plan 9 or FreeBSD -
INTR is hardly pure C ;-)... Yes, you have some point, but not too
serious one. Ironic, since the unusual (compared to other system calls)
part doesn't require any assembler...