On Tue, Jul 14, 2020 at 4:01 PM Rodolfo Giometti <giometti@xxxxxxxxxxxx> wrote: > I see... however attached is a new version of my proposal patch I looked a bit at this! IIUC the idea is a "new" sysfs interface that does not require the exporting etc used by the current "old" sysfs interface. Instead of poking around in sysfs to export lines we do that from the device tree. It also does not use any global GPIO numbers which would be my other main concern. I must admit that it has some elegance to it. Especially when it comes to scripting. The problem I see is that lines are left in whatever state they were in if a script crashes, so there is no "return to the initial value" that was there when the GPIOs were picked from the device tree. This makes this a bit fragile. Also users regularly need to listen to events. This interface can and should never support that, for this one must use the character device, which will of course not work in parallel with using this sysfs ABI. And the day someone wants that we simply have to say no. There is no way to hold states for event handling in a stateless ABI. Well of course they can poll for a line to change, but that is not proper event handling that reacts to an interrupt. So while this is much more elegant the old sysfs ABI, and certainly better for scripting, it still suffers from some conflicts with the character device, and there is a risk to make users dissatisfied when they want to e.g. script event handlers. What are your thoughts on this? Yours, Linus Walleij
