Subject: Re: cpu_fork(), it bends my brain
To: None <thorpej@zembu.com>
From: Anders Magnusson <ragge@ludd.luth.se>
List: port-vax
Date: 05/25/2000 20:42:04
> 
> Yah, I understand the basic principle :-)  I was mostly just confused about
> the VAX's details.  You have clarified them.  And I think I've even found
> a bug! :-)
> 
>  >         nyproc->PC = tf->pc;	<- user space program counter after trap
>  >         nyproc->PSL = tf->psl & ~PSL_C; <- PSL have privileges of process
>  > 					   (kernel/user privileges)
>  >         nyproc->R[0] = p1->p_pid; /* parent pid. (shouldn't be needed) */
>  >         nyproc->R[1] = 1;	<- R0/R1 have return values
> 
> Right, ok, so this is effectively what child_return() does on most
> platforms.  I'll reference the hp300's trap.c for simplicity.
> 
> The problem here is that the VAX is failing to do a few things upon
> child return in a fork():
> 
> 	- Not delivering any signals that may have been sent to
> 	  the process before it gets a chance to run.  (done in
> 	  userret()).
> 
I assume that it is _very_ unlikely that a process gets a signal before
it has even started :-) But in theory it is possible, yes.

> 	- Missing the child's KTRACE point for fork return (done
> 	  in child_return()).
> 
That's a good point. I assume that code is older than KTRACE :-)

> The VAX's return-to-userspace-from-trap should probably be made to
> look more like the hp300's, if nothing else, to reduce the duplication
> of code (VAX has 2 copies of what is effectively userret()), and to
> get the KTRACE point.
> 
That's by optimization issues, I assume. A subroutine call on a 11/750
takes 27 uS just the calls/ret pair, and if 1000 traps per second is
done that's quite a high number :-)

>  > I assume that you don't provide a PC if it's a normal fork :-)
> 
> Actually, I was thinking of just providing "child_return" as the
> kernel trampoline function, since every port has one .. well, except
> for VAX :-)  But I'm hoping you'll change that.  Or I could.  Now that
> I understand what's going on there... :-)
> 
No problem, in this case it won't matter so much (an extra rei after each
fork, but I assume that won't hurt anyone :-) 

I can write child_return() if it do not matter for you...

-- Ragge