Allow wrapping an existing /dev/fuse file descriptor

[colinmarc]

This is important for container runtimes, which need to do a special namespace mount dance.

Fixes #300. This is a less invasive version of #301, but I like that one better.

[cberner]

Let's make this optional instead of removing it

[colinmarc]

What is the utility of getting the mountpoint back out, after you just passed it in? Especially if it returns an Option<PathBuf>?

[cberner]

The getter doesn't seem useful, but it seems nice to have the logging

[colinmarc]

Added the logging back.

[cberner]

I think it would be better to have a mount_to_fd() function similar to mount() that instead returns the FD. That better separates the concerns of creating the mountpoint, which won't even need to have a Filesystem implementation.

[colinmarc]

This is just for symmetry - I'm not using it, so I can remove it if you don't like it. Note that the stdlib equivalents all support this (File, various sockets, etc).

[cberner]

How would someone use it though?

The reason it doesn't seem right to me is that a Session represents a mounted filesystem, borrowing its fd, and reading/writing it would interfere with the Filesystem that is mounted and feels like it breaks the encapsulation.

[colinmarc]

How would someone use it though?

By passing it into mount(2)/fsconfig(2) to mount the session somewhere.

In my use case, you need to mount first and then create the session. But it's not hard to imagine someone needing to do it the other way around.

EDIT: I just thought of another one. You could unset CLOEXEC or do some other fcntl stuff on the session if you needed to.

EDIT2: You could also use it to call fuse ioctls, perhaps ones that aren't supported by this library yet (eg file passthrough).

[colinmarc]

Zooming out a bit:

I would like to submit that FUSE is a very low-level concept, and it's often used as a hack-on-demand. So people using it probably know what they're doing, and may have complicated requirements. A fuse session is a /dev/fuse file descriptor - therefore it fulfills the requirements of AsFd.

I do see the concerns around breaking the encapsulation, but Channel is not actually stateful, right? So it's really very similar to UnixStream or whatever. If you call AsFd on a UnixStream and drop down to nix::io::write or whatever, you probably have a very specific use case that the stdlib authors didn't think of.

[cberner]

Good points. Thanks for explaining the use case!