I should probably wait until tomorrow to think about this, but I'm
going to have a stab at it anyway. Forgive me if it's less coherent
than usual.

Gregory McGarry <g.mcgarry@ieee.org> writes:

> During bootstrap, curproc statically refers to &proc0.  MD bootstrap code
> will always run with curproc != NULL.
> 
> During bootstrap on the nathanw_sa branch, curproc statically refers
> to &lwp0.  MD bootstrap code will always run with curproc != NULL, and
> with curproc->l_proc == NULL.


> Unfortunately, there is an implicit assertion on the nathanw_sa
> branch, that when curproc != NULL, then curproc->l_proc != NULL.
> This isn't true for MD code which is invoked before main().

Yes. LWPs should always be associated with processes. Otherwise, there
are no pointers to e.g. their VM space.

> (1) simultaneously check for (curproc != NULL) && (curproc->l_proc != NULL)
>     in MD code;

Shouldn't be necessary.

> (2) statically set curproc = NULL during bootstrap; or
> 
> (3) nuke all references to curproc from MD code.

There's also:

(4) make lwp0->l_proc statically point to proc0. This seems like the
    least-invasive option.

> I'm not sure what the implications of option (2) are.

Nor I. What are some MD pre-main() uses of curproc? There's a certain
sensiblity to leaving the curproc pointer NULL until there is a
structure with useful data to be pointed to. However, if MD bootstrap
code is responsible for filling in parts of proc0/lwp0, this could be
a problem.


>  I believe that the use of curproc has escaped beyond its original
> intention.  Certainly, there are many unnecessary uses of curproc in
> MD code which can be removed. But I'm not sure option (3) is
> realistic.

I think that (3) is right out, as a practical matter.

        - Nathan