Re: replacement for persistence of values written to sysfs files

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

On Mon, Mar 15, 2021 at 1:53 PM Rasmus Villemoes
<linux@xxxxxxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> I'm sure this has been asked before, so please just refer to me any old
> thread(s) where this has been discussed.
>
> In the bad old sysfs days, the value assigned to the gpio via the
> /sys/class/... interface was persistent. So it was easy to use in shell
> scripts etc. But gpioset very clearly states
>
> Note: the state of a GPIO line controlled over the character device
> reverts to default
> when the last process referencing the file descriptor representing the
> device file exits.
> This means that it's wrong to run gpioset, have it exit and expect the
> line to continue
> being driven high or low. It may happen if given pin is floating but it
> must be interpreted
> as undefined behavior.
>
> and I don't see anything in v2 of the uapi changing that.
>
> So how is one supposed to get the kernel to set and maintain a value for
> a gpio, without having to keep a dummy process around? Also, with the
> sysfs interface, another process can later change the gpio value; I
> don't think that's possible with a dummy process hanging onto it.
>
> So, for example, one init script we have first configures a temperature
> sensor with a high-temp alert threshold, and after that value has been
> written, sets a gpio that will make such an alert trigger a reset of the
> board. That gpio must of course stay set, but it cannot be set before
> the threshold has been programmed. Then the init script starts a simple
> service that periodically logs the temperature reading. A human being
> working on the board can temporarily disable the alert-triggered reset
> by just writing 0 to the gpio.
>
> The README says
>
> Additionally this project contains a set of command-line tools that should
> allow an easy conversion of user scripts to using the character device.
>
> but I don't see how to achieve the persistence (or ability by
> third-party to temporarily change the value) provided by sysfs.

My understanding is that the character device interface lacks some
kind of (D-Bus based) daemon for this.

Note, the state of values (their persistence) depends on the hardware
driver as far as I can see in case of x86 (so, we have the gpioset,
while being context less,  be persistent). But I completely agree
that's undefined behaviour.

-- 
With Best Regards,
Andy Shevchenko