On Wed, Nov 27, 2019 at 2:35 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > This series adds a new ioctl() that allows user-space to retrieve a > file-descriptor which can then be polled for events emitted by the kernel > when the line is requested, released or its status changed. This of course > doesn't require the line to be requested. Multiple user-space processes > can watch the same lines. So if I understand correctly all the series do is expose metadata about all GPIO lines to userspace? I think up until now the use case assumptions have been: - The kernel will pick off some GPIO lines, mostly during boot but occasionally at runtime (by users such as kernel modules or hotlugged devices). - Userspace will pick some lines from those that are available, after the kernel picked those it wants. If it tries to pick one of those that the kernel already picked, the request will be denied. The assumption (at least in my head) was that the GPIOs the kernel picks will not be a very dynamic business. So this appears to be dealing with this very dynamic business. Is the *main* use case different userspace processes trying to use the same pins and getting denied? Because in that case we might be putting a bit too much userspace plumbing into the kernel and we need to think about that for a while. (Binder and kdbus etc comes to mind.) So there is some feature growth happening here and I want to be aware of the whole picture. On a side track: There is a bit about policy that needs to happen here I suppose, like for example what if the kernel actually wants one of the lines that userspace has picked? Should userspace be kicked out and kernel get what it wants? (Arguably yes.) Yours, Linus Walleij