linux-kernel - Re: [PATCH RFC 3/6] iio: core: Add cleanup.h support for iio_device_claim

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aTSUpUb5MLX9s0Xz@smile.fi.intel.com>
Date: Sat, 6 Dec 2025 22:40:05 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>,
	Kurt Borja <kuurtb@...il.com>,
	David Lechner <dlechner@...libre.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	Benson Leung <bleung@...omium.org>,
	Antoniu Miclaus <antoniu.miclaus@...log.com>,
	Gwendal Grignou <gwendal@...omium.org>,
	Shrikant Raskar <raskar.shree97@...il.com>,
	Per-Daniel Olsson <perdaniel.olsson@...s.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Andy Shevchenko <andy@...nel.org>,
	Guenter Roeck <groeck@...omium.org>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
	chrome-platform@...ts.linux.dev
Subject: Re: [PATCH RFC 3/6] iio: core: Add cleanup.h support for
 iio_device_claim_*()

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@...il.com> wrote:
> > On Thu, Dec 4, 2025 at 7:18 PM Kurt Borja <kuurtb@...il.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