Investigate use of overlay filesystem to implement a driver for GPIO mirroring

[flongo82]

If we want to use drivers for mirroring GPIO filesystems from one node to another we probably will need to use overlay filesystems on both the master node (from which the GPIO is mirrored) and the slave node (to which the GPIO is mirrored).

[gmerlino]

In terms of (overlay-/union-like) filesystems, either we could resort to in-kernel OverlayFS (or simply Overlay), but that requires kernel 3.18+, or to userspace ones, the only one I found is this: https://github.com/rpodgorny/unionfs-fuse

If we want to have a shared mount point but obtain different views of the filesystem, the answer may lie in overlays plus "mount namespaces" (CLONE_NEWNS, already available in kernel 3.3 it seems): each process would have its own namespace and see its own "layer" of the (possibly multiple) system overlays.

This would leave the question open to what the behaviour of such setup would be.

Another issue, maybe to be spun out as a separate one, is whether we can be as granular as possible with GPIO filesystems, given the nature of board.connect or similar primitives, which initialize the whole "board" (i.e., reset GPIO states wholly).

A possible solution could lie in initializing GPIO only at driver (fs) instantiation time, and fake/no-op any further requests for initialization, e.g., those coming from remote clients.

This is to be investigated by looking more deeply into the inner workings of example libraries (LininoLib) and the semantics of GPIO initialization.