Re: [RFC PATCH 0/3] xen/spinlock: make recursive spinlocks a dedicated type

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

On 12/14/22 10:31, Juergen Gross wrote:
> On 14.12.22 16:03, Daniel P. Smith wrote:
> > On 9/10/22 11:49, Juergen Gross wrote:
> > > Instead of being able to use normal spinlocks as recursive ones, too,
> > > make recursive spinlocks a special lock type.
> > >
> > > This will make the spinlock structure smaller in production builds and
> > > add type-safety.
> > Just a little yak shaving, IMHO a spinlock is normally not expected to 
> > be recursive. Thus explicitly naming a spinlock as non-recursive I 
> > find to be redundant along with being expensive for typing. Whereas a 
> > recursive spinlock is the special instance and should have a 
> > declarative distinction. Only codifying the recursive type would 
> > significantly cut down on the size of the series and still provide 
> > equal type and visual clarification.
> A "normal" spinlock is non-recursive.
>
> A recursive spinlock in Xen can be either taken recursive, or it can be 
> taken
> non-recursive, causing further recursive attempts to spin.
Yes, I understand the current situation.

> So the explicit non-recursive locking applies to that special treatment of
> recursive spinlocks.
I understand this, but to help clarify what I am saying is that 
individuals coming from outside Xen would expect is the spinlock family 
of calls to behave as a non-recursive spinlocks and recursive spinlock 
family of calls would provide the recursive behavior. Currently Xen's 
behavior is backwards to this, which this series continues and is a 
valid approach. Here spinlock and recursive spinlock family of calls are 
recursive and must use non-recursive spinlock family to have "normal" 
spinlock behavior. IMHO it would greatly simplify the code and align 
with the "normal" understanding of spinlocks if instead 
spin_{lock,locked,unlock} macros were the non-recursive calls and 
spin_{lock,locked,unlock}_recursive macros were the recursive calls. 
Then there would only be two suites of calls for spinlocks and a lot 
less keystrokes for need for most development.
v/r,
dps