Directly use a `Mirage_kv.RW` instead of a `Mirage_block.S` and compose that with a specific file-system

[dinosaure]

The idea will be to unlock the ability to let the end-user to choose its implementation of the file-system. By this way, the unikernel.ml will require a Mirage_kv.S directly and we will let the config.ml/the end-user to choose which implementation of the KV-store he/she wants.

[palainp]

I currently need the block for the encryption layer (encryption gives me back a block that a use as a kv store with chamelon) because this was my usecase (having an mountable encrypted directory). Anyway, thanks for the suggestion I'll think about it and may drop the encryption layer in favor of the usability to choose the underlying fs :+1:

[dinosaure]

I'll think about it and may drop the encryption layer in favor of the usability to choose the underlying fs 👍

In such case, it's probably good to have a thin-layer such as:

module With_CCM = functor (Mirage_block.S) -> Mirage_block.S

And make it as a mirage/functoria device 🙂 . In the config.ml, it will be:

let my_initial_block = block_of_file "disk.img"
let my_block_with_ccm = block_with_encryption `CCM my_initial_block
let my_fs = chamelon my_block_with_ccm

let () = main $ my_fs

[palainp]

I merged the branch changing mirage_block to mirage_kv.RW. It should be fine now, and you can try that (with a minor edition of src/config.ml) using mirage-kv-mem with:

ssh-keygen -t ed25519 -C mirage_sshfs -f test -N '' && \
chmod 600 test && \
./src/dist/mirage_sshfs --user test --key "$(cat test.pub | sed 's/ /\\ /g')"

And in another terminal:

sshfs test@127.0.0.1:/ /tmp/ssh/ -o IdentityFile=/absolute/path/to/privkey/test