Re: [PATCH net-next v2 7/8] docs: netdev: break down the instance locking info per ops struct

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 10 Apr 2025 22:35:43 +0000 Keller, Jacob E wrote:
> > > Does this mean we don't allow drivers which support
> > > netdev_queue_mgmt_ops but don't set request_ops_lock? Or does it mean
> > > that supporting netdev_queue_mgmt_ops and/or netdev shapers
> > > automatically implies request_ops_lock? Or is there some other
> > > behavioral difference?
> > >
> > > From the wording this sounds like its enforced via code, and it seems
> > > reasonable to me that we wouldn't allow these without setting
> > > request_ops_lock to true...  
> > 
> > "request" is for drivers to optionally request.
> > If the driver supports queue or shaper APIs it doesn't have a say.  
> 
> Which is to say: if you support either of the new APIs, or you
> automatically get ops locking regardless of what request_ops_lock is,
> so that if you do support one of those interfaces, there is no
> behavioral difference between setting or not setting request_ops_lock.
> 
> Ok, I think that's reasonable.

Right, and FWIW we may one day actually make the request_ops_lock 
bit be _the_ decider and auto-set it based on op presence when netdev
is registered. Purely to simplify the condition in netdev_need_ops_lock().
For now it isn't that. I was worried if I go into too much detail here
we'll then forget to update it and stale docs are worse than no docs :(