linux-kernel - Re: [PATCH v2 0/2] gpio: create the /sys/class/gpio mount point with GPIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2024101531-lazy-recollect-6cbe@gregkh>
Date: Tue, 15 Oct 2024 11:29:56 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Kent Gibson <warthog618@...il.com>, linux-kernel@...r.kernel.org,
	linux-gpio@...r.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v2 0/2] gpio: create the /sys/class/gpio mount point with
 GPIO_SYSFS disabled

On Tue, Oct 15, 2024 at 10:00:22AM +0200, Bartosz Golaszewski wrote:
> Greg, Rafael,
> 
> The first patch in this series is small but may be seen as controversial
> so here's a little backstory.

Ah, now I see the 0/2 email...

> We have two sets of GPIO APIs currently in the kernel: the legacy one
> based on numbers and the modern one using descriptors. Our goal is to
> remove the old one from the kernel to which there are two obstacles: the
> first one is easier and consists of converting all remaining in-kernel
> users to the preferred API. This is tedious but it's all within our
> control, just demands a lot of effort. The second obstacle is much harder
> as it involves removing an existing kernel uABI that is the GPIO sysfs
> interface at /sys/class/gpio.
> 
> Despite providing a number of user-space tools making using the GPIO
> character device easier, it's become clear that some users just prefer
> how the sysfs interface works and want to keep using it. Unless we can
> provide a drop-in replacement, they will protest any attempts at
> removing it from the kernel. As the GPIO sysfs module is the main user
> of the global GPIO numberspace, we will not be able to remove it from
> the kernel either.

They should protest it's removal, and you should support it for forever,
as that's the api that they rely on and you need to handle.  That's the
joy of kernel development, you can't drop support for stuff people rely
on, sorry.

> I am working on a FUSE-based libgpiod-to-sysfs compatibility layer that
> could replace the in-kernel sysfs and keep all the user-space programs
> running but in order to keep it fully compatible, we need to be able to
> mount it at /sys/class/gpio. We can't create directories in sysfs from
> user-space and with GPIO_SYSFS disabled, the directory is simply not
> there.

Ick, no, just keep the kernel stuff please.

> I would like to do what we already do for /sys/kernel/debug,
> /sys/kernel/config, etc. and create an always-empty mount point at
> /sys/class/gpio. To that end, I need the address of the /sys/class
> kobject and the first patch in this series exports it.

No, debug and config are different, they are not "fake" subsystems, they
are totally different interfaces and as such, can use those locations as
mount points for their in-kernel filesystem interfaces.  You are wanting
a random userspace mount point, that's totally different.

Sorry, just live with the kernel code please.  Work to get all userspace
moved off of it if you feel it is so bad, and only then can you remove
it.

greg k-h