> Date: Wed, 7 Feb 2018 14:14:35 +0900
> From: Ryota Ozaki <ozak...@netbsd.org>
>
> On Wed, Feb 7, 2018 at 2:55 AM, Taylor R Campbell
> <campbell+netbsd-tech-k...@mumble.net> wrote:
> >> Date: Tue, 6 Feb 2018 19:06:33 +0900
> >> From: Ryota Ozaki <ozak...@netbsd.org>
> >>
> >> So I think we should do either:
> >> (1) fix rw_lock_held, or
> >> - probably it would be rw_read_held() || rw_write_held()
> >> (2) fix users of rw_lock_held.
> >> - it also would replace rw_lock_held with
> >> rw_read_held() || rw_write_held()
> >>
> >> I prefer (1) because I think there is no user of the current
> >> behavior that is difficult to use for users (it may be useful
> >> as an internal utility function though).
> >
> > I like (1) too, but check for Solaris compatibility? It is hard to
> > imagine that there are correct uses of the current semantics that are
> > not also correct uses of (1).
>
> https://docs.oracle.com/cd/E36784_01/html/E36886/rwlock-9f.html
>
> They seem to have only rw_read_locked that is compatible to our
> rw_read_held.
Looks to me like rw_read_locked is actually more like:
KASSERT(rw_read_held(l) || rw_write_held(l));
return rw_read_held(l);
or
KASSERT(rw_read_held(l) || rw_write_held(l));
return !rw_write_held(l);
But it turns out that our rw_init is API-incompatible with Solaris's
anyway, so I guess it's all kinda moot, so I'd say just go for (1).
