Re: [RFC] GSoC 2026: Transitioning IIO to guard() and scoped_guard()

["Ethan Tidmore" <ethantidmore06@gmail.com>]

On Sat Mar 14, 2026 at 6:07 AM CDT, Jonathan Cameron wrote:
> On Wed, 11 Mar 2026 22:18:07 +0200

...

>
> Hi Ethan
>
> I'm not keen on a mass cleanup like this without taking a closer look at
> the drivers. I would say (based on gut feeling rather than actually
> having checked the stats) that perhaps 25% of these patches result in
> feedback on the surrounding code or follow on improvements that are
> enabled. 

That makes sense. That would be a ton of time spent on reviewing this.

...

> As to the your question on how this 'might' be done, it would need to be
> 1 patch per driver because this will cause chaos for backports of later
> fixes due to significant churn.

Yeah, that kills the idea entirely. I was hoping it could be done per
vendor per dir but, I understand why that wouldn't work.

>
> There are ABI changes that we want to push through the tree such
> as iio_push_to_buffers_with_ts() but that's because the new ABI
> is inherently safer and I want to get rid of the old one.
> Some of those cases are easy, others much less so.

If a tree wide conversion to iio_push_to_buffers_with_ts() would be
wanted I'd be glad to do that. There is much less volume for this
project and if completed then a deprecated function could be removed.

$ grep -rn "iio_push_to_buffers_with_timestamp" drivers/iio/ | wc -l
73

And this would be much more manageable to review. Would this be a viable
proposal for GsoC?

Thanks,

ET