Re: GPIO static allocation warning with v6.2-rcX

[Sascha Hauer <sha@xxxxxxxxxxxxxx>]

On Thu, Jan 26, 2023 at 10:35:22AM +0100, Linus Walleij wrote:
> On Wed, Jan 25, 2023 at 10:35 AM Sascha Hauer <sha@xxxxxxxxxxxxxx> wrote:
> 
> > You are trying to remove the GPIO sysfs API for many years now without
> > success so far, and I doubt that you will succeed in future because the
> > Kernel comes with the promise that userspace won't be broke.
> 
> I see it more as permanent deprecation and nudging than removal as of now.

I am fine with permanent nudging. The sysfs API is deprecated and it's
ok to remind people that there's a new API they should use instead, but
as said, please don't actively break this API. Well to be correct,
adding this warning is not breaking the API by itself, instead it
motivates other people to do so, so you're getting there even without
making your own hands dirty ;)

> 
> For some reason people perceive all nudging as militant and as a
> my-way-or-the-highway style of communication but it's not really intended.
> OK maybe I am softer now than in the past, one grow humbler with
> old age.
> 
> It will become more interesting once we removed all in-kernel users of
> the global numberspace, which is well underway. At that point we can
> move the management of the global numberspace into the sysfs code
> and distros etc that don't want to use it can compile it out completely.

Perfectly fine with me. As I said: Push the sysfs API into a corner
where it hurts nobody let it stay there.

> 
> But the idea was never to slam people to not use something they use and like,
> it was to offer something new because they want it and like it more.
> 
> So using the character device with libgpiod users can:
> 
> - Get and set multiple lines at the same time
> - Do biasing (if supported by HW) pull up/down
> - Do drive strength (if supported by HW)
> - Properly listen to IRQ-driven events on lines with real-time timestamps
>   to ensure strict event order
> - Use HTE timestamps (new feature!)
> - libgpiod for the above with C, C++, Python and Rust bindings
> 
> By offering those new tasty features only for the character device and not
> for the sysfs ABI, at least the advanced users are expected to switch over
> to using the character device.

Ack, perfectly fine with me. Providing new features only for the new API
is a good way of gently pushing people towards the new API.

What's missing is a way to let a GPIO stay in the current state when I
release a GPIO chip. Unlike the new features you listed above this is a
feature that the sysfs API offers and that's important for us.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |