If you wanted to support old kernels, and you had sysfs support, then I would've added uAPI v2 support and left sysfs in place as a fallback option.
Or add v2 support with v1 as the fallback - that is what my Go and Rust libraries do. Btw, if you want to do that you can probe using GPIO_V2_GET_LINEINFO_IOCTL on offset 0 to test if v2 is present. That beats checking kernel versions IMHO.
People moving from sysfs to v1 bothers me as v1 is also deprecated. It will eventually go away as well. Then we'll get the same "hey where did that interface go?" dramas that we are seeing for sysfs now. Plan for v1 to be gone.
And they might be making life difficult for themselves by following the v1 object model and then not being able to map the more generalised v2 into it. That was the reason there had to be a libgpiod v2 rather than just extending v1 to support the v2 uAPI - the v1 object model was exposed in the libgpiod API. OTOH if you start with v2, as my libraries did, then v1 is just a subset that maps into it, and there are just some features you can't support using v1 - like debounce. Having said that, WiringPi provides a streamlined interface that only deals with requests on single pins, right? If so you are probably ok on that front. Either way, it's water under the bridge now.
Oh, and if you aren't aware, the GPIO documentation in the kernel has recently been revamped, for both v1 and v2. Probably worth a read.
Or add v2 support with v1 as the fallback - that is what my Go and Rust libraries do. Btw, if you want to do that you can probe using GPIO_V2_GET_LINEINFO_IOCTL on offset 0 to test if v2 is present. That beats checking kernel versions IMHO.
People moving from sysfs to v1 bothers me as v1 is also deprecated. It will eventually go away as well. Then we'll get the same "hey where did that interface go?" dramas that we are seeing for sysfs now. Plan for v1 to be gone.
And they might be making life difficult for themselves by following the v1 object model and then not being able to map the more generalised v2 into it. That was the reason there had to be a libgpiod v2 rather than just extending v1 to support the v2 uAPI - the v1 object model was exposed in the libgpiod API. OTOH if you start with v2, as my libraries did, then v1 is just a subset that maps into it, and there are just some features you can't support using v1 - like debounce. Having said that, WiringPi provides a streamlined interface that only deals with requests on single pins, right? If so you are probably ok on that front. Either way, it's water under the bridge now.
Oh, and if you aren't aware, the GPIO documentation in the kernel has recently been revamped, for both v1 and v2. Probably worth a read.
Statistics: Posted by warthog618 — Fri May 10, 2024 1:21 am