Aymeric Vincent <vincent@labri.fr> writes:

> Darrin B. Jewell wrote:
> 
> > I've added an argument to simple_lock_init(9), SIMPLELOCK_INITIALIZER,
> > and pool_init(9) which encodes a minimum spl level which is required
> > for all uses of that lock or pool.
> 
> I think it would be better to use new functions that take this extra
> parameter (simple_lock_init_spl() or something like that) because it
> would make the migration easier: you could commit the "highlights"
> part of your diff right now and calls to simple_lock_init() and
> pool_init() could then be changed later.

No, all calls to simple_lock_init() and pool_init() that need the spl
argument would have to be changed up front.  Otherwise, they will fail
immediately when LOCKDEBUG is turned on.  Committing the highlights is
not useful until after a first pass is done on all the locks.  That is
also why this is done only in the LOCKDEBUG case and is careful not to
have any impact unless LOCKDEBUG is enabled.

> 
> The other reason is because it looks bad to me to force a user of the
> locking or (worse) pool API to know about SPLs.

That's the whole point!  This is done to force people to explicitly
codify the intended use of their lock or pool with respect to
interrupts.  This does not add any new constraints or functionality,
and just verifies constraints which have been documented in pool(9)
lock(9) and spl(9) for some time.  I will add information to those man
pages which states that locks or pools that are not involved in any
interrupt context should use IPL_NONE.

I really only want to consider adding separate `spl' locks calls if it
is done on an entirely new simple_lock_spl type.  And the only reason
to desire two separate simple_lock types is for eventual performance
if we ever decide to have a combined spl/simple_lock primitive in the
future.  I took a look at this possibility and decided that if we ever
do this, we can change the locks with a search and replace at that
time and don't need to do it now.

Darrin

> 
> Otherwise, I think it should prove a very good debugging tool, as (I
> believe) your recent commits show and I think it's a good idea to have
> something like this committed.
> 
> Regards,
>   Aymeric