That *is* one value: a single command, to execute atomically! :)
ISTR seeing that done elsewhere, and have seen various proposals
that rely on that working. In any case, the one-per-file rationale
was to make things easier for userspace.
Next version. If the "is this interface OK" part of the RFC flies,
then additional effort on docs would not be wasted.
Good point, I'll move such stuff out of #ifdefs. I almost
did that this time, but this way made for a simpler patch. ;)
Yeah, the isue there is that the attribute files may
still be open after the GPIO has been unexported. For
this specific method the existing spinlock can solve
that problem ... but not in general.
Seems like a general fix for that should involve a mutex
covering all those sysfs actions: read, write, export,
and unexport. The unexport logic would need reworking,
but the rest could work pretty much as they do now (but
while holding that lock, which would protect that flag).
But that wouldn't change the user experience; the sysfs
attributes would still look and act the same.
That would indeed be better. Maybe I should whip up a sysfs
patch adding that, and have this depend on that patch. (I've
CC'd Greg in case he has comments on that...)
Alternatively: strict_streq(), analogy to strict_strto*()?
Yes. But as with quite a lot of "rmmod" type paths, there's
no way to report it to the caller. I'll add a pr_debug().
Yeah, kind of ugly. Not particularly happy with that, but
I wasn't keen on allocating a temporary copy of that string
either...
So it does. That was leftover from a version with
a more complex control interface. Easy to remove
the lines'o'code following *that* comment!
Or just use negative numbers to mean "unexport";
ugly and hackish, but functional.
I don't want to see the components of one command
split into separate files, where they could be
clobbered by a second userspace activity ...
Yes, see below ... there's a minor penalty to be paid.
I'll just make it #ifndef CONFIG_GPIO_SYSFS ... that will make the
interface impossible to provide without gpiolib, but I'm not much
concerned about that.
Note that putting it *here* covers the case of platforms that provide
standard GPIO interfaces but don't use the newish gpiolib code to do
that ... which is why putting it in an #else (above) didn't suffice.
--
