Jason Thorpe wrote:

> On Fri, 28 May 1999 17:36:43 +1000 
>  Simon Burge <simonb@netbsd.org> wrote:
> 
>  > >     atomic_value_t v1 = ATOMIC_INIT_RESET;
>  > >     atomic_value_t v2 = ATOMIC_INIT_SET;
>  > > 
>  > >     int atomic_set(atomic_value_t *v);
>  > > 	set *v; return 1 if it wasn't already set.
>  > >     void atomic_reset(atomic_value_t *v);
>  > > 	reset *v.
>  > >     int atomic_isset(atomic_value_t *v);
>  > > 	return 1 if *v is set, otherwise 0.
>  > 
>  > And this interface would live in <atomic.h> or <sys/atomic.h>?  If
>  > we need a kernel implementation (as for older MIPS chips), then
>  > <sys/atomic.h> would be the way to go...
>  > 
>  > I'll put together a full proposal.
> 
> <machine/atomic.h> is the right thing, I think, since it's inherently
> machine-dependent.

I was thinking along the lines of <sys/atomic.h> more or less just
including <machine/atomic.h>, but I guess there's no need for the
extra level on indirection.

> Also note some of the atomic operations that arch/alpha/alpha/atomic.s
> implements...
> 
> 	- atomic test-and-set (for spin locks)
> 
> 	- atomic load-and-latch (for atomically reading a counter and
> 	  resetting it to zero, for example)

I was only thinking in terms of Bill's interface for now.  Would this
do for now?  One thing that's missing is the size of "atomic_value_t".
Maybe that should be "atomic_set32" and so on...

Am I right in saying that each new interface to atomic operations
would require bumping either libc's minor number and/or the kernel's
alphabetic release number, even if only one architecture extends the
interface?

Simon.