Selectively mount folders under /sys/devices/platform/soc/3f200000.gpio/gpio

[flongo82]

We need to mount the folder under /sys/devices/platform/soc/3f200000.gpio/gpio corresponding to a GPIO pin only when the pin is actually exported. Similarly, the folder needs to be unmounted when the pin is unexported.

These are the first functionalities that come into my mind and that should be (easily?) implementable if this feature is implemented:

• if an application on a virtual rasp exports a pin, this should not be visible on other virtual rasps running on the same physical rasp
• a virtual rasp could be forbidden to export a pin
• a pin on a virtual rasp is not mapped to the corresponding physical pin but rather it is mapped on a (dummy) unconnected pin

[flongo82]

First step in this direction is to study what happens when a pin is exported and unexported, i.e., what is the exact sequence of syscalls while performing a:

echo 1 > /sys/class/gpio/export

or a

echo 1 > /sys/class/gpio/unexport

After that we should:

• capture the syscall
• check if the physical pin is already exported
• if not export it
• mirror the corresponding folder under /sys/devices/platform/soc/3f200000.gpio/gpio
• attach it to the container

If we are able to do that we could remove the part of the creation of a virtual rasp where we mirror the whole /sys/devices/platform/soc/3f200000.gpio/gpio and attach it to the container.

[flongo82]

If you activate the logs uncommenting the lines with console.log in each FUSE operation and you try to perform a

echo 1 > /sys/class/gpio/export

what are the syscalls that are invoked?

[maratstepanov]

Logging is not commented as I see (second line is logging calls):

var getattr_function = function(path, cb){
        console.log('getattr(%s)',path);
        fs.lstat(pt.join(original_folder, path), function(err, stats){
            if(err){
                //console.log('error: ', err);                
                cb(fuse[err.code]);
            }
            else{
                cb(null,stats);
            }
        });
    }

But when I perform echo 1 > /sys/class/gpio/export nothing is being logged.
At the same time gpio1 folder is being created in /sys/class/gpio/ and mirrored to /gpio_mnt/test1/sys/class/gpio folders
When I performecho 1 > /gpio_mnt/test1/sys/class/gpio/export (with unexporting it in advance, of course), then get the following in the log:

getattr(/export)
open(/export)
getxattr_function(/export)
stats:  Stats {
... omitted stats output ...
}
truncate(/export)
getattr(/export)
getxattr_function(/export)
stats:  Stats {
... omitted stats output ...
}
write(/export)

As I understand, it checks current attributes of export file and perform write by last action.

[flongo82]

When you perform echo 1 /sys/class/gpio/export on the physical rasp you are not interacting in any way with our software so it is normal that you do not have any log. Of course the gpio1 folder is being created in /sys/class/gpio and then you see it in the mirrored folder (/gpio_mnt/test1/sys/class/gpio).

Have you performed echo 1 > /gpio_mnt/test1/sys/class/gpio/export from within the virtual rasp or outside? However, in both cases you are interacting with our software so you see the logs.

I can see that, apart from getattr and gettxattr, the relevant operations are open, truncate, and write.

I think that we can neglect open and truncate and we can capture the write operation.

Basically, what we need to do is modify the function corresponding to the write mirroring and check what is the file that is being written. If it is the export file, then we do the operations that I wrote above.

[maratstepanov]

I was interacting with physical rasp, right.

Have you performed echo 1 > /gpio_mnt/test1/sys/class/gpio/export from within the virtual rasp or outside? However, in both cases you are interacting with our software so you see the logs.

I did it from outside.

Basically, what we need to do is modify the function corresponding to the write mirroring and check what is the file that is being written. If it is the export file, then we do the operations that I wrote above.

Will investigate it and come back.

[maratstepanov]

I have implemented selective mount, but there are some limitations:

• one to one mapping only (you cannot pin one physical pin to few virtual ones)
• mapped /sys/class/gpio folder shows all exported pins to all containers. But container can interact with the ones that were exported by them only. This is caused by the fact that /sys/class/gpio is mapped fully.
• no error handling in write procedure. It always returns "no error" to client.

[flongo82]

Ok, I have few questions (just to better understand without checking the code yet):

• Why only one to one mapping is possible? I did not get that.
• Mapped /sys/class/gpio folder shows all exported pins probably because of the presence of the links. But (and this is probably the reason why you are saying that the container that exported the pin is the only one that can interact with it), links to pins that have not been exported by the container should be broken because the corresponding folder under /sys/devices/platform/soc/3f200000.gpio/gpio is not there. Can you confirm that? Two ways to solve this come into my mind: 1) we could check if it is possible to understand if a link is broken and if it is possible we could filter them modifying the syscalls that show lists of files; 2) if we do not want to check broken links we should maintain the information about which container exported which pin and filter the links accordingly to such an information - always modifying the syscalls that show lists of files.
• What kind of error handling should we insert? I mean, right now what kind of error can be experienced by the client? In order to make the experience within the container exactly the same as the one on a physical rasp we should check what kind of errors can be experienced when interacting with GPIO sysfs. For example, what happens on a physical rasp if I try to export a pin that does not exist?

[maratstepanov]

Why only one to one mapping is possible? I did not get that.

Because there is currently no logic to map physical pins to virtual ones. Phyisical pin is being exported by "pin number" > /gpio_mnt/sys/class/gpio/export command in container.
I can add more functionality, and track pins usage - physical pin will be unexported only if its not exported to any of containters.

links to pins that have not been exported by the container should be broken because the corresponding folder under /sys/devices/platform/soc/3f200000.gpio/gpio is not there. Can you confirm that?

Correct: links to pins exported by other containters are broken, and containter cannot use them.

1. we could check if it is possible to understand if a link is broken and if it is possible we could filter them modifying the syscalls that show lists of files

I think that this could be implemented. During investigation I have already found out that if we try opening attrbiutes of folder with broken link, we get at error. We can leverage it and modify corresponding syscall.

2. if we do not want to check broken links we should maintain the information about which container exported which pin and filter the links accordingly to such an information - always modifying the syscalls that show lists of files.

This approach requres keeping data somewhere - I suggest the first approach as it doesn't require it.

What kind of error handling should we insert?

For example, if physical pin is already exported, we get "Device is busy" error. Maybe we should answer the same way to virtual rasp if it tries to export pin that is already exported to it. There could be some more error types.

For example, what happens on a physical rasp if I try to export a pin that does not exist?

Need to check that, but I'm sure there will be some error - not just silently accepting the command.

[flongo82]

I can add more functionality, and track pins usage - physical pin will be unexported only if its not exported to any of containters.

This is something we should implement. The last unexport operation to a virtual pin should also trigger an unexport of the corresponding physical pin. I mean that it should work as follows:

• when the first virtual pin corresponding to a physical one is exported, if the physical pin is not already exported, it should be exported
• subsequent export operation of a virtual pin corresponding to the same physical one (in another virtual rasp different from the one from which it has been exported the first time) should not trigger a corresponding export operation on the physical one but we should only start mirroring the corresponding folder.
• subsequent export operation of a virtual pin corresponding to the same physical one (in the same virtual rasp from the one from which it has been exported the first time) should cause an error (the same error it is experienced on a physical rasp when trying to export a pin twice.
• an unexport operation performed inside one of the virtual rasps from which the pin has been exported should not trigger an unexport operation on the physical rasp but it should just cause the mirroring of the corresponding folder to stop
• the last unexport operation within a virtual rasp should also cause the unexport of the physical pin.

You can open a new issue for these feature if you want even if I think it is related to this one.

[flongo82]

This approach requres keeping data somewhere - I suggest the first approach as it doesn't require it.

I agree with that but I'm pretty sure that eventually we will have to keep some data in memory to keep track of what is happening inside the virtual rasps. Thus, I would go for the second approach. I also think that, with multiple virtual rasps, it could be difficult to understand if a pin has been exported within a virtual rasp or another one. Would you do that by looking for which virtual rasp that pin folder is being mirrored?

I opened a new issue for this new feature so let's continue discussing there about it.