Jason Thorpe wrote:
> 
> [ NOTE: I am addressing several reposonses in this message, so everyone
>   please pay attention. :-]
> 
> On Tue, 27 Jul 1999 09:56:00 -0700 (PDT)
>  "Eduardo E. Horvath" <eeh@one-o.com> wrote:
> 
>  > Locks need to have an spl() associated with them.  Otherwise code could
>  > grab a lock and be interrupted, and the interrupt handler could try to
>  > grab that lock once again.
> 
> Yes, I understand that.  However, currently several places in the kernel
> already do:
> 
>         s = splfoo()
>         simple_lock(...);
>         .
>         .
>         .
>         simple_unlock(...);
>         splx(s);

OK lets define the (S)MP semantics of spl*().
Do we block the interrupts on the affected processor or on all processors?
Only if it blocks interrupts on all processors this method prevents 
deadlocks.

> 
> So, this issue can be addressed later.  Yes, I agree its an issue, but
> it touches a lot more code, affects every platform, and needs to have
> a new, separate API in place first.  My goal right now is to make
> incremental improvement in the right direction, mostly so that Big Lock
> can be committed soon.

The old locks can be implemented by locally interrupt blocking spinlocks too
(and globally blocking spls).

But it still would not eliminate the deadlock problem without globally 
blocking spls completely (but the debugger would still work :-))).

[...]

> 
> Okay, I can see that cpu_info[] needs to be more flexible.  The problem
> with requiring per-CPU-page mapped to the same VA on all processors is
> that it greatly complicates memory management on some architectures (for
> example, the Alpha), whereas on others, this is very simple (for example,
> the MIPS and SPARC).
> 

And impossible on a PA RISC. It can't have an alias for a physical page, 
so mapping that page privately per cpu and globally for all wouldn't work.

> How about the following:
> 
> #if defined(MULTIPROCESSOR)
> #define curproc         curcpu()->ci_curproc
> #else
> extern struct proc *curproc;
> #endif
> 
> I.e. introduce a curcpu() macro which returns a pointer to the cpu_info
> structure for the current CPU.  Then the platform can implement this
> in any way it chooses (cpu_info[...] or per-CPU-page).

OK.
Stefan

> 
>         -- Jason R. Thorpe <thorpej@nas.nasa.gov>