Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes: #13
Initial draft for 9P host and guest implementations.
Seems to work for read-only stuff. Still need to do tests with writable systems since some required operations are probably missing implementations at the moment.
(I had this working a few months ago but forgot to publish the draft. Oops.)
Example server/host invocation:
fs mount 9p ipfs $multiaddr
would host the IPFS API on
$multiaddr
which a client could then attach to.Example guest/client invocation:
fs mount fuse 9p -9p-server $multiaddr $mountpoint
would attach to
$multiaddr
and mount it (via FUSE) at$mountpoint
The invocation names and flags may change. Suggestions welcomed.
I'm not sure if
9p-server
,9p-client
would be better than keeping them both as just9p
.We only support 9P2000.L at the moment, but this may change in the far future. If/when it does we'd probably support a
-protocl-version
flag to select specific ones, or they could be broken out into a unique command namespace.E.g.
fs mount 9p2000l ipfs ...
but this may be too verbose and not sensible to implement compared to a singular9p
with flags.