Mapping physical pins to virtual ones

[flongo82]

Design a mechanism to map physical pins with virtual pins in terms of naming, filtering, and so on.

[flongo82]

The GPIO pseudo-filesystem under /sys/class/gpio seems to work as follows.

When the Rasp is freshly booted, the content of /sys/class/gpio is the following:

total 0
-rwxrwx--- 1 root gpio 4096 Mar 28 11:15 export
lrwxrwxrwx 1 root gpio    0 Feb 11  2016 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio    0 Feb 11  2016 gpiochip100 -> ../../devices/platform/soc/soc:virtgpio/gpio/gpiochip100
-rwxrwx--- 1 root gpio 4096 Mar 28 11:26 unexport

while the content of /sys/devices/platform/soc/3f200000.gpio/gpio is the following:

total 0
drwxrwx--- 3 root gpio 0 Feb 11  2016 gpiochip0

As soon as a pin is exported with:

# echo 1 > /sys/class/gpio/export

a new folder appears in /sys/devices/platform/soc/3f200000.gpio/gpio:

total 0
drwxrwx--- 3 root gpio 0 Mar 28 11:30 gpio1
drwxrwx--- 3 root gpio 0 Feb 11  2016 gpiochip0

and a link is created in /sys/class/gpio:

total 0
-rwxrwx--- 1 root gpio 4096 Mar 28 11:30 export
lrwxrwxrwx 1 root gpio    0 Mar 28 11:30 gpio1 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio1
lrwxrwxrwx 1 root gpio    0 Feb 11  2016 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio    0 Feb 11  2016 gpiochip100 -> ../../devices/platform/soc/soc:virtgpio/gpio/gpiochip100
-rwxrwx--- 1 root gpio 4096 Mar 28 11:26 unexport

[flongo82]

To emulate how GPIO pseudo-filesystem actually works in a more precise way and to have more flexibility, we need to mount each folder under /sys/devices/platform/soc/3f200000.gpio/gpio when the corresponding pin is exported and not in a preemptive way as done right now.

See #5.

[flongo82]

Official documentation of GPIO sysfs:

https://www.kernel.org/doc/Documentation/gpio/sysfs.txt

[maratstepanov]

Possibly, we can start doing this.
We can change the JSON body of POST request to the following:

{
  "name": "name",   //container name
  "gpiomapping": {
    "1": "1" //name is virtual pin, value is corresponding physical pin
    "7": "4" //name is virtual pin, value is corresponding physical pin
    "default": "action" // action could be: prohibit (do not allow to export any virtual pin, exceping listed above), allow (allow exporting any other virtual pins, they will correspond to the same physical ones)
  }
}

[flongo82]

Yes, it is okay with me. My only doubt is about what happens in your example if user try to export pin 4 and action is "allow". Of course, this should be something the physical rasp admin should take care of but probably it would be better to put in place a mechanism that prevent this kind of issues. Moreover, what happen if a user tries to export a pin that is prohibited? Should he experience an error? This would be against the fact that the virtual rasp should behave exactly as a physical one.

I would prefer something like:

• pins explicitly mentioned in the giomapping section are mapped accordingly to it;
• pins that are not mentioned are faked, i.e., they are emulated as not-attached pins.

In order to implement the second possibility, we should understand what happens when a pin is disconnected an one tries to export it, read it, write to it, etc.

What do you think?

[flongo82]

By the way, I would say that among the currently opened issues this is the one at highest priority.

[maratstepanov]

I would prefer something like:

pins explicitly mentioned in the giomapping section are mapped accordingly to it;
pins that are not mentioned are faked, i.e., they are emulated as not-attached pins.

This is better than my proposal, let's do it this way.

[maratstepanov]

In order to implement the second possibility, we should understand what happens when a pin is disconnected an one tries to export it, read it, write to it, etc.

Performed different actions to disconnected pin:
echo 4 > /sys/class/gpio/export = actualy export goes on;
echo "666" > /sys/class/gpio/gpio4/direction = "write error: Invalid argument"
echo "out" > /sys/class/gpio/gpio4/direction = succesfully writes
echo "in" > /sys/class/gpio/gpio4/direction = succesfully writes
cat /sys/class/gpio/gpio4/value (when it's in "in" state) = 1
cat /sys/class/gpio/gpio4/value (when it's in "out" state) = 0
cat /sys/class/gpio/gpioX/direction (after boot and export) = in (it put's to in by default, but if we change it to out, unexport pin and export it again, it will be out - it means that state is being saved)

[flongo82]

Ok I believe that emulating a disconnected pins is not an easy task because we should change each syscall to take into account if it has as argument the emulated pin and to avoid performing the same call on the physical rasp in that case.

I would say that in a first moment we should try to work on changing the pin names accordingly to the pin mapping. Later, we can try to work on emulating the disconnected pins.

[maratstepanov]

The commit above does the following:

• on POST accepts with gpiomapping and writes it to file
• during export from inside of container, checks file with gpiomapping and exports appropriate physical pin (the same during import)
• during readattr and readlink replaces answer according to gpiomapping

Now we can start with emulating unconnected pin, I think. Should we create appropriate folder structure and emulate behavior of gpio? What exact approach do you propose?

[flongo82]

If you map every single pin (so no unconnected pin) everything works properly? I'm asking because I'm wondering if readattr and readlink are sufficient to correctly manage the mapping. What about read and write syscalls or others?

Regarding the emulation of unconnected pins, I think that the easier thing to do is create a folder structure that exactly reproduce the one of a GPIO pin somewhere in the filesystem of the physical rasp and then mirroring it changing the name of the pin accordingly to the mapping.

Then, we need to study how a disconnected pin behaves in terms of read and write operations and fake the results of such calls.

What do you think?

[maratstepanov]

If you map every single pin (so no unconnected pin) everything works properly? I'm asking because I'm wondering if readattr and readlink are sufficient to correctly manage the mapping. What about read and write syscalls or others?

Yes. It seems that other syscalls rely on readattr and readlink (because they are also being called when I perform write).

Regarding the emulation of unconnected pins, I think that the easier thing to do is create a folder structure that exactly reproduce the one of a GPIO pin somewhere in the filesystem of the physical rasp and then mirroring it changing the name of the pin accordingly to the mapping.
Then, we need to study how a disconnected pin behaves in terms of read and write operations and fake the results of such calls.
What do you think?

I thought about the same, actually. I'll start working on it today.