Pure Erlang implementation of 9p2000 protocol
filesystem
fs
9p2000
erlang
9p
1<!--
2SPDX-FileCopyrightText: 2025 Łukasz Niemier <~@hauleth.dev>
3
4SPDX-License-Identifier: Apache-2.0
5-->
6
7# e9p
8
9Implementation of [9p2000][] file protocol in Erlang
10
11## Goals
12
13- [x] Message parsing
14- [ ] Client implementation
15 + [ ] Establishing connection
16 + [ ] Tree walking
17 + [ ] IO server implementation for reading/writing files
18 + [ ] File/directory creation
19 + [ ] File/directory deletion
20 + [ ] File stats
21- [ ] Server implementation
22 + [x] Establishing connection
23 + [x] Tree walking
24 + [x] File/directory creation
25 + [x] File/directory deletion
26 + [x] File stats
27 + [x] Customisable FS implementations
28
29### Example FS
30
31- [x] UnixFs - which will simply allow accessing some "real" directory in
32 system FS. **WIP**: Implemented directory traversal, file
33 writing/reading/deletion, but so far no file nor directory creation.
34- [x] ErlProcFS - which will expose Erlang process tree and other internal data
35 via API similar to `procfs` from Linux. Read-only for the time of being.
36
37## Reasoning
38
39I want to implement `procfs`-like API for Erlang to allow non-Erlang-fluent
40operators to navigate through Erlang processes. There is something similar
41implemented in [`fuserl`][fuserl], but that uses [`libfuse`][libfuse], which is
42[NIF][] implemented. That requires compilation of native code and can be
43problematic wrt cross compilation and stuff. On the other hand [9p2000][] is
44network protocol that can be implemented fully in Erlang, thus do not require
45any additional tools or compilation steps. It can also be accessed remotely if
46needed.
47
48[9p2000]: http://ericvh.github.io/9p-rfc/rfc9p2000.html
49[fuserl]: https://github.com/tonyrog/fuserl
50[libfuse]: https://github.com/libfuse/libfuse
51[NIF]: https://www.erlang.org/doc/system/nif.html#
52
53## License
54
55Apache-2.0 with exception to PropEr tests which are GPL-3.0-only. This do not
56affect possibility to run this project as dependency of non-GPL projects, as GPL
57code is not used in runtime. Unfortunately that workaround is needed due to
58PropEr licensing.