On Mon, Feb 27, 2023 at 9:56 PM Benjamin Li <benl@xxxxxxxxxxxx> wrote: > > On 2/25/23 6:10 AM, Bartosz Golaszewski wrote: > > I applied patch 2/3 as it's a fix. For the rest of them - my goal for > > the v1.6.x series is to not support it anymore, than is absolutely > > necessary - that means no new features and android build looks like > > one to me. Any chance you can carry this locally? > > Sure, we don't mind. But I'd like to gently remind that a lot of device > manufacturers like us have platforms that are unfortunately stuck on > older kernel versions that don't have the v2 IOCTLs. > Ah, right. Android again. :) Does the android build file need to live in the top source directory? Can it go into a separate contrib/ directory where this kind of less maintained stuff could go? > Are there plans to introduce backwards compatibility to libgpiod v2 > to support pre-5.10 kernels without v2 IOCTLs? I assume no based on > your talk from July since there's a major data model re-architecture. > Not really, as the previous uAPI is quite limited and a lot of features of libgpiod v2 would no longer work. > Anyways, as an aside it would be nice to note in the README about the > 5.10-or-later requirement for libgpiod v2 (apologies if it's mentioned > and I missed it). Sounds good I will add it. Unfortunately it's impossible to know the kernel version at build-time so configure checks are useless. We also carry our own copy of the kernel uAPI headers for other reasons so checking the target's headers won't fly either. Bart > > I didn't learn about the compatibility gap until I tested libgpiod v2 > tools on-device and found that they failed without a sufficiently new > kernel. Bummer as I was looking forward to being able to reference > GPIOs by just the labels in the CLI! > > > > > For v2.x I'm open to adding it but have a couple comments, see the > > relevant email threads. > > Thanks, will respond there. > > Ben > > > > > Bart