This may be a bit out of date considering the message about adding spl()
to simple_lock() but here goes:

On Thu, 29 Jul 1999, Jason Thorpe wrote:


Do we still need:

> 	u_long cpu_number(void);

if we have:

> 	struct cpu_info *curcpu(void);

I suppose that cpu_number could become:

#define cpu_number	curcpu()->ci_cpuid

> 	int cpu_lock_spl(int);
> 
> 		MANDATORY
> 
> 		This function, inline function, or macro performs
> 		the appropriate spl*() operation according to
> 		the provided LK_SPL_* token (see below).  Its return
> 		value will be passed to splx().

I do not understand this at all.  This is a replacement of splx()?  What
does it have to do with locks?

> 	SIMPLELOCK_LOCKED
> 	SIMPLELOCK_UNLOCKED

I'm not entirely happy about this.  I would like to use CASX to store a
pointer to the proc that's attempting to grab the lock (to aid debugging).
Rather than directly comparing them as values I think it would be more
general to have macros that take a pointer to a lock and return true or
false:

#define	SIMPLELOCK_LOCKED(l)	((l)->lock_data != 0)

(NB: better than using __aligned would be to have the type of lock_data
defined in  <machine/lock.h>.)

> The following functions or macros will be exported by <machine/lock.h>:
> 
> 	void cpu_simple_lock_init(__volatile struct simplelock *alp);
> 
> 		MANDATORY
> 
> 		This function, inline function, or macro initializes
> 		the `lock_data' member of `struct simplelock' to the
> 		value SIMPLELOCK_UNLOCKED.

One thing that always bothered me about this is that the lock is
initialized to the unlocked state, which means there's a hole where some
other thread could try to grab the lock right after it's initialized.  I
would be happier if it initialized the lock to SIMPLELOCK_LOCKED.


=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me