* libgpiod API v2 release @ 2022-07-12 7:48 Alexandre Ghiti 2022-07-14 3:10 ` Kent Gibson 0 siblings, 1 reply; 5+ messages in thread From: Alexandre Ghiti @ 2022-07-12 7:48 UTC (permalink / raw) To: linux-gpio Hi, Ubuntu kernels do not enable GPIO_CDEV_V1 as it is deprecated, but the libgpiod package that we ship is still based on the latest version 1.6.3 which does not implement the API v2. So I'd like to update libgpiod, do you have any recommendations about what branch/sha1 I should use? Do you plan to make a release that implements the API v2? Thanks, Alex ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libgpiod API v2 release 2022-07-12 7:48 libgpiod API v2 release Alexandre Ghiti @ 2022-07-14 3:10 ` Kent Gibson 2023-03-29 11:03 ` Dimitri John Ledkov 0 siblings, 1 reply; 5+ messages in thread From: Kent Gibson @ 2022-07-14 3:10 UTC (permalink / raw) To: Alexandre Ghiti; +Cc: linux-gpio, brgl On Tue, Jul 12, 2022 at 09:48:45AM +0200, Alexandre Ghiti wrote: > Hi, > > Ubuntu kernels do not enable GPIO_CDEV_V1 as it is deprecated, but the > libgpiod package that we ship is still based on the latest version > 1.6.3 which does not implement the API v2. So I'd like to update > libgpiod, do you have any recommendations about what branch/sha1 I > should use? Do you plan to make a release that implements the API v2? > Firstly, libgpiod is Bart's library so he is the authority, but this is my understanding... TLDR: You should keep GPIO_CDEV_V1 enabled. v1 is deprecated from a development perspective, so all new feature development will occur on v2, and new applications should target v2. Existing apps targetting v1, be that directly or via libgpiod v1.6.3, will require GPIO_CDEV_V1 until they migrate to v2. The mainline kernel will continue to support v1 while userspace transitions. libgpiod v2 is in active development, and should reach its first release shortly. Note that it is NOT a plugin replacement for v1. It has a different API, for similar reasons to why we had to switch in the kernel, so apps will need to be actively migrated. I wouldn't suggest making any effort to package libgpiod v2 until Bart makes an official release. Cheers, Kent. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libgpiod API v2 release 2022-07-14 3:10 ` Kent Gibson @ 2023-03-29 11:03 ` Dimitri John Ledkov 2023-03-29 11:36 ` Kent Gibson 0 siblings, 1 reply; 5+ messages in thread From: Dimitri John Ledkov @ 2023-03-29 11:03 UTC (permalink / raw) To: linux-gpio; +Cc: brgl, Kent Gibson Hi, On 14/07/2022 04:10, Kent Gibson wrote: > On Tue, Jul 12, 2022 at 09:48:45AM +0200, Alexandre Ghiti wrote: >> Hi, >> >> Ubuntu kernels do not enable GPIO_CDEV_V1 as it is deprecated, but the >> libgpiod package that we ship is still based on the latest version >> 1.6.3 which does not implement the API v2. So I'd like to update >> libgpiod, do you have any recommendations about what branch/sha1 I >> should use? Do you plan to make a release that implements the API v2? >> > > Firstly, libgpiod is Bart's library so he is the authority, but this > is my understanding... > > TLDR: You should keep GPIO_CDEV_V1 enabled. > > v1 is deprecated from a development perspective, so all new feature > development will occur on v2, and new applications should target v2. > Existing apps targetting v1, be that directly or via libgpiod v1.6.3, > will require GPIO_CDEV_V1 until they migrate to v2. > The mainline kernel will continue to support v1 while userspace > transitions. > > libgpiod v2 is in active development, and should reach its first release > shortly. > Note that it is NOT a plugin replacement for v1. It has a different API, > for similar reasons to why we had to switch in the kernel, so apps will > need to be actively migrated. > > I wouldn't suggest making any effort to package libgpiod v2 until Bart > makes an official release. > > Cheers, > Kent. > libgpiod v2 is out now at least upstream, even if it is not yet packaged in most distributions. But this brings newly identified loss of functionality that seems to be impossible to resolve so far. With the v1 API, it was possible to do fine-grained access and mediation control via LSM. Specifically privileged process would export pins, and then use LSM controls to allow rw access to individual pin path in sysfs to otherwise unpriviledged or confined applications. This is used a lot on Ubuntu Core with snapd and apparmor, to mediate confined applications (such that only one application at time has access to a particular pin, and to ensure they only have access to pins they need). It doesn't seem to be possible to do such mediation with v2 api, as I don't see any LSM hooks inside the gpiochip ioctl implementation, and the character device is for the full chip, not individual pins. Similarly, mediating ioctl calls requires a lot of gpio ioctl specific knowledge (i.e. introspecting gpio_v2_line_values masks and what not). Thus right now, I cannot migrate to v2 api, as I would loose confinement capabilities. And there is external pressure to stop using "DEPRECATED" config option in the kernel that "will be removed after 2020" as per comments and Linux documentation. What is the LSM plan for v2 API, if any? Ideally, it would be nice to have lsm hook to check/filter operations on allowed pin numbers. Or for example, can we add ability to create filtered char device that self-limits itself to particular lines only, within a particular chip? As then the usual LSM could mitigate access to that, without specific gpio ioctl knowledge / introspection. (e.g. /dev/gpio/my-gpio-pins that only allows access to gpiochip0 lines 0..100) Regards, Dimitri. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libgpiod API v2 release 2023-03-29 11:03 ` Dimitri John Ledkov @ 2023-03-29 11:36 ` Kent Gibson 2023-03-29 11:42 ` Dimitri John Ledkov 0 siblings, 1 reply; 5+ messages in thread From: Kent Gibson @ 2023-03-29 11:36 UTC (permalink / raw) To: Dimitri John Ledkov; +Cc: linux-gpio, brgl On Wed, Mar 29, 2023 at 12:03:31PM +0100, Dimitri John Ledkov wrote: > Hi, > > On 14/07/2022 04:10, Kent Gibson wrote: > > On Tue, Jul 12, 2022 at 09:48:45AM +0200, Alexandre Ghiti wrote: > > > Hi, > > > > > > Ubuntu kernels do not enable GPIO_CDEV_V1 as it is deprecated, but the > > > libgpiod package that we ship is still based on the latest version > > > 1.6.3 which does not implement the API v2. So I'd like to update > > > libgpiod, do you have any recommendations about what branch/sha1 I > > > should use? Do you plan to make a release that implements the API v2? > > > > > > > Firstly, libgpiod is Bart's library so he is the authority, but this > > is my understanding... > > > > TLDR: You should keep GPIO_CDEV_V1 enabled. > > > > v1 is deprecated from a development perspective, so all new feature > > development will occur on v2, and new applications should target v2. > > Existing apps targetting v1, be that directly or via libgpiod v1.6.3, > > will require GPIO_CDEV_V1 until they migrate to v2. > > The mainline kernel will continue to support v1 while userspace > > transitions. > > > > libgpiod v2 is in active development, and should reach its first release > > shortly. > > Note that it is NOT a plugin replacement for v1. It has a different API, > > for similar reasons to why we had to switch in the kernel, so apps will > > need to be actively migrated. > > > > I wouldn't suggest making any effort to package libgpiod v2 until Bart > > makes an official release. > > > > Cheers, > > Kent. > > > > libgpiod v2 is out now at least upstream, even if it is not yet packaged in most distributions. But this brings newly identified loss of functionality that seems to be impossible to resolve so far. > You are confusing uAPI v1 with the long deprecated sysfs API. uAPI v2 is a functional superset of v1 - anything that can be done with v1 can also be done with v2, and the ioctl approach is the same. But replacing "v1 API" with "sysfs API" and the following makes more sense... > With the v1 API, it was possible to do fine-grained access and mediation control via LSM. Specifically privileged process would export pins, and then use LSM controls to allow rw access to individual pin path in sysfs to otherwise unpriviledged or confined applications. This is used a lot on Ubuntu Core with snapd and apparmor, to mediate confined applications (such that only one application at time has access to a particular pin, and to ensure they only have access to pins they need). > > It doesn't seem to be possible to do such mediation with v2 api, as I don't see any LSM hooks inside the gpiochip ioctl implementation, and the character device is for the full chip, not individual pins. Similarly, mediating ioctl calls requires a lot of gpio ioctl specific knowledge (i.e. introspecting gpio_v2_line_values masks and what not). > > Thus right now, I cannot migrate to v2 api, as I would loose confinement capabilities. And there is external pressure to stop using "DEPRECATED" config option in the kernel that "will be removed after 2020" as per comments and Linux documentation. > > What is the LSM plan for v2 API, if any? > Here we go again. sysfs has been deprecated since 2015, and yet you are only now looking to migrate away from it. Please specify exactly how much notice you require not to feel "pressured". > Ideally, it would be nice to have lsm hook to check/filter operations on allowed pin numbers. > > Or for example, can we add ability to create filtered char device that self-limits itself to particular lines only, within a particular chip? As then the usual LSM could mitigate access to that, without specific gpio ioctl knowledge / introspection. (e.g. /dev/gpio/my-gpio-pins that only allows access to gpiochip0 lines 0..100) > Use the GPIO aggregator[1] to create a chip confined to the pins of interest? Then you can use LSM, or whatever, to control access to the chip? Cheers, Kent. [1] https://www.kernel.org/doc/html/latest/admin-guide/gpio/gpio-aggregator.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libgpiod API v2 release 2023-03-29 11:36 ` Kent Gibson @ 2023-03-29 11:42 ` Dimitri John Ledkov 0 siblings, 0 replies; 5+ messages in thread From: Dimitri John Ledkov @ 2023-03-29 11:42 UTC (permalink / raw) To: Kent Gibson; +Cc: linux-gpio, brgl Hi, On Wed, 29 Mar 2023 at 12:36, Kent Gibson <warthog618@gmail.com> wrote: > > On Wed, Mar 29, 2023 at 12:03:31PM +0100, Dimitri John Ledkov wrote: > > Hi, > > > > On 14/07/2022 04:10, Kent Gibson wrote: > > > On Tue, Jul 12, 2022 at 09:48:45AM +0200, Alexandre Ghiti wrote: > > > > Hi, > > > > > > > > Ubuntu kernels do not enable GPIO_CDEV_V1 as it is deprecated, but the > > > > libgpiod package that we ship is still based on the latest version > > > > 1.6.3 which does not implement the API v2. So I'd like to update > > > > libgpiod, do you have any recommendations about what branch/sha1 I > > > > should use? Do you plan to make a release that implements the API v2? > > > > > > > > > > Firstly, libgpiod is Bart's library so he is the authority, but this > > > is my understanding... > > > > > > TLDR: You should keep GPIO_CDEV_V1 enabled. > > > > > > v1 is deprecated from a development perspective, so all new feature > > > development will occur on v2, and new applications should target v2. > > > Existing apps targetting v1, be that directly or via libgpiod v1.6.3, > > > will require GPIO_CDEV_V1 until they migrate to v2. > > > The mainline kernel will continue to support v1 while userspace > > > transitions. > > > > > > libgpiod v2 is in active development, and should reach its first release > > > shortly. > > > Note that it is NOT a plugin replacement for v1. It has a different API, > > > for similar reasons to why we had to switch in the kernel, so apps will > > > need to be actively migrated. > > > > > > I wouldn't suggest making any effort to package libgpiod v2 until Bart > > > makes an official release. > > > > > > Cheers, > > > Kent. > > > > > > > libgpiod v2 is out now at least upstream, even if it is not yet packaged in most distributions. But this brings newly identified loss of functionality that seems to be impossible to resolve so far. > > > > You are confusing uAPI v1 with the long deprecated sysfs API. > uAPI v2 is a functional superset of v1 - anything that can be done with > v1 can also be done with v2, and the ioctl approach is the same. > > But replacing "v1 API" with "sysfs API" and the following makes more > sense... Yes I am, apologies. > > > With the v1 API, it was possible to do fine-grained access and mediation control via LSM. Specifically privileged process would export pins, and then use LSM controls to allow rw access to individual pin path in sysfs to otherwise unpriviledged or confined applications. This is used a lot on Ubuntu Core with snapd and apparmor, to mediate confined applications (such that only one application at time has access to a particular pin, and to ensure they only have access to pins they need). > > > > It doesn't seem to be possible to do such mediation with v2 api, as I don't see any LSM hooks inside the gpiochip ioctl implementation, and the character device is for the full chip, not individual pins. Similarly, mediating ioctl calls requires a lot of gpio ioctl specific knowledge (i.e. introspecting gpio_v2_line_values masks and what not). > > > > Thus right now, I cannot migrate to v2 api, as I would loose confinement capabilities. And there is external pressure to stop using "DEPRECATED" config option in the kernel that "will be removed after 2020" as per comments and Linux documentation. > > > > What is the LSM plan for v2 API, if any? > > > > Here we go again. sysfs has been deprecated since 2015, and yet you are > only now looking to migrate away from it. > Please specify exactly how much notice you require not to feel "pressured". I guess lack of knowledge about gpio-aggregator was the missing piece, rather than any particular timelines. > > > Ideally, it would be nice to have lsm hook to check/filter operations on allowed pin numbers. > > > > Or for example, can we add ability to create filtered char device that self-limits itself to particular lines only, within a particular chip? As then the usual LSM could mitigate access to that, without specific gpio ioctl knowledge / introspection. (e.g. /dev/gpio/my-gpio-pins that only allows access to gpiochip0 lines 0..100) > > > > Use the GPIO aggregator[1] to create a chip confined to the pins of interest? > Then you can use LSM, or whatever, to control access to the chip? > This looks exactly what Ubuntu Core / snapd wants, thus I will investigate implementing that. > Cheers, > Kent. > > [1] https://www.kernel.org/doc/html/latest/admin-guide/gpio/gpio-aggregator.html > -- okurrr, Dimitri ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-03-29 11:42 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-07-12 7:48 libgpiod API v2 release Alexandre Ghiti 2022-07-14 3:10 ` Kent Gibson 2023-03-29 11:03 ` Dimitri John Ledkov 2023-03-29 11:36 ` Kent Gibson 2023-03-29 11:42 ` Dimitri John Ledkov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).