Re: [PATCH RFC 3/6] iio: core: Add cleanup.h support for iio_device_claim_*()

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Sat, Dec 06, 2025 at 06:43:32PM +0000, Jonathan Cameron wrote:
> On Thu, 4 Dec 2025 19:36:28 +0200
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Thu, Dec 4, 2025 at 7:18 PM Kurt Borja <kuurtb@gmail.com> wrote:
> > > On Wed Dec 3, 2025 at 5:34 PM -05, David Lechner wrote:  
> > > > On 12/3/25 3:50 PM, David Lechner wrote:  
> > > >> On 12/3/25 1:18 PM, Kurt Borja wrote:  

...

> > > If we rename iio_device_claim_direct() (which is huge), maybe we can
> > > pick shorter names and more descriptive names while at it? I was
> > > thinking something like:
> > >
> > >         iio_mode_lock()
> > >         iio_mode_lock_direct()
> > >         iio_mode_lock_buffer()
> > >         iio_mode_unlock()  
> > 
> > The device context is important, so at least iio_dev_mode_lock() (and so on).
> 
> If we are bringing lock into the name do we need to make it explicit which can fail?
> Given you can't use them in the wrong place, maybe not.
> 
> iio_mode_lock_try_direct() or maybe iio_mode_lock_direct_try()?

For locking the pattern is to have *_trylock()

> This was less relevant when they all could fail.  Maybe we don't need to
> bother given how rarely used the unconditional ones are.
> 
> I did like the claiming of mode terminology because it made it a little
> more clear that we were taking a lock that was there for a purpose rather than
> a normal lock.  Also the fact it's a lock is an implementation detail I'd
> rather not back into the ABI.
> 
> Maybe it's worth something inspired by Rafael's patch linked above?
> 
> #define IIO_DEV_ACQUIRE_DIRECT_MODE(_dev, _var) \
> 	ACQUIRE(iio_device_claim_direct, _var)(_dev);
> #define IIO_DEV_ACQUIRE_BUFFER_MODE(_dev, _var) \
> 	ACQUIRE(iio_device_claim_buffer, _var)(_dev);
> 
> For the two more complex ones and fine using guard() for the rare
> any mode variant.
> 
> Then we can have whatever naming we like for the helpers under
> the hood as no one will ever use them directly.
> 
> Hohum. Hardest problems in computer science etc, coherency and naming. :)
> 
> > > Shorter names will also keep lines short when using guards.  

-- 
With Best Regards,
Andy Shevchenko