Inject a filesystem via stdio.
It's like sshfs, but reverse (and eventually without ssh).
It's like NFS, but without a server.
May embedded device, such as smart home and IoT are very limited regarding to their (non-volatile) memory resources. Such devices are typically based on embedded linux system.
Some use cases, like updating the firmware, creating backups or restoring them require to handle (larger) files:
- during a firmware update, the firmware image is typically stored somewhere on device
- unless backups can be streamed, (larger) files are typically buffered somewhere on device
- unless restore can be streamed, (larger) files are typically buffered somewhere on device
For such use caes, it would be nice to inject a remote file system to provide or store these files.
During development phase, there are also use cases that may require to provide some data to the device, e.g. providing debug information or additional tools.
One approach is NFS, which comes really in handy during development. Unfortunately, NFS requires a server where the device needs to connect to. So the NFS approach is often not suitable in productive environments.
Many embedded linux based devices contain an SSH for maintenance purposes. Therefore, it is preferrable to use this existing and secure protocol to inject a file system. Sshfs allows to mount a virtual files system using fuse on the host PC and delegates all file system requests to the target. This is pretty much the reverse direction for the most use cases decribed above.
The idea of stdiofs is to reverse the direction of sshfs in order to inject a file system on a host PC to the target device. Therefore, stdiofs consists of two binaries:
- stdiofs_provider: a tool running on the host PC, which replies to file system requests
- stdiofs: a fuse-based tool on the target device, which delegates all filesystem requests to the calling process
Stdiofs does not establish any SSH connection by itself. Instead stdiofs_provider forks a process an commuicate via stdin and stdout. The forked process can be ssh which connects to to target device and executes stdiofs there.
Typically, stdiofs will be used like this:
stdiofs_provider -p /some/path -- sshpass -p secret ssh user@target stdiofs -f -s /path/to/mountpoint
Technically, stdiofs can use every tunnel that provides communication via stdin and stdout. For testing purposes, it can even be used without any tunnel.
stdiofs_provider -p /some/path -- stdiofs -f -s /path/to/mountpoint
mkdir build
cd build
cmake ..
make
make install
| Option | Type | Description |
|---|---|---|
| WITHOUT_TESTS | bool | Disable build of unit tests |
| WITHOUT_STDIOFS | bool | Disable build of stdiofs binary |
| WITHOUT_PROVIDER | bool | Disable build of provider binary |
Stdiofs uses a binary protocol which is communicated between stdiofs provider and the stdiofs process.
Since stdiofs uses stdin and stdout for communication, it does not make much sence to run it in daemon mode. Therefore, option -f should be provided in most use cases.
Since stdiofs uses a strict request-reply scheme, it does not make much sence to run it multithreaded. A mutex is used to enforce the communication scheme. Therefore, running stdiofs in multithreded mode does not lead to any errors, but wastes resources. Option -s should be provided to run in single-threaded mode.