• virtiofs: turn off FUSE_DESTROY for virtiofs

There are two outstanding bugs that need fixing before this can be merged:

• virtiofs: rename 'tag' VFS option to 'from'
• address feedback

Unnecessary since the generic mount utility can mount/unmount virtiofs.

address reviewer feedback

In D46296#1101873, @editor_callfortesting.org wrote:

Could someone provide some simple scripts for bringing up and testing a share?

In D46296#1060950, @val_packett.cool wrote:

A couple more notes from testing:

There's some other place where FUSE layer can pick up zero-padded-to-power-of-two things, now with 1024 instead of 4096:

WARNING: FUSE protocol violation for server mounted at /: Returned an embedded NUL from FUSE_READLINK.  This warning will not be repeated.
Len 1024
0000   62 61 73 68 00 00 00 00 00 00 00 00 00 00 00 00  |bash............|
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
…

And trying to just find something in a src tree checkout, there are sporadic errors like

find: ./contrib/llvm-project/llvm/lib/DebugInfo/Symbolize: Bad file descriptor
find: ./sys/dev/qat/qat_hw: Invalid argument
find: ./sys/dev/qat/qat_api/common/stubs: Invalid argument
// etc…

that seem completely random, on one invocation there are none, on another there's a couple…

In D46297#1057513, @asomers wrote:

Can you add a man page, too?

Thanks for the feedback! I will update the diff accordingly.

In D45370#1038548, @asomers wrote:

Will do, I have been building it as part of the kernel so that's probably why it didn't need a definition in sys/modules. I have been running this manually.

I've been thinking on how to get this code to be more reviewable. Should I maybe try to get it published as a port instead of submitting it as a patch to src/? Most of this code is self-contained, and its size means it will be next to impossible to review in its current state. If we go down the port route, only changes we would be applying to src/ would be non-functional - most would be about turning some static functions global.

Alternatively, I can break this diff apart, get the virtio-dbg transport reviewed since it is more reasonably sized, and either spin off the userspace device emulation component as a port or introduce it later. Which do you think is more reasonable?

Splitting it apart sounds good. Especially if there's some way to exercise the virtio-dbg transport without the userspace device emulation. Then splitting it apart would be a very good idea.

In D45370#1035488, @asomers wrote:

I think you need to add a definition for the virtio_dbg module in sys/modules. Oh, and how do you use it? Eventually we want ATF tests, of course. But I assume for now you've been manually using it somehow?