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. 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. 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. It's not like we're unaware about the upsides of the sysfs ABI. Easy to use to do quick hacks. Always there. I have been trying to think of e.g. a debugfs ABI that would be even easier to use for even quicker hacks, but using only local per-gpiochip offsets, see the bottom of the TODO file: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/TODO Yours, Linus Walleij