special-case getvfsbyname(3) for fusefs(5)

[asomers]

Summary

special-case getvfsbyname(3) for fusefs(5)

fusefs file systems may have a fsname subtype (set by mount_fusefs's "-o
subtype" option) that gets appended to the fsname as returned by statfs(2).
The subtype is set on a per-mount basis so it isn't part of the struct
vfsconf. Special-case getvfsbyname to match either the full "fusefs.foobar"
or short "fusefs" fsname.

This is a merge of r348007, r348054, and r350093 from projects/fuse2

Test Plan

1. Mount a subtyped fusefs by doing:

fuse-ext2 /dev/vtbd2 /mnt -o subtype=ext2

2. List it with:

lsvfs -t fusefs
lsvfs -t fusefs.ext2

Both commands should succeed

[kib]

lib/libc/gen/getvfsbyname.c

55

I would say that strcmp() success excludes a possibility to match e.g. "fusefs.foo" string. Did you mean '||' instead of '&&' ?

82

I do not like this change. I suggest you to add a new flag to vfsflag e.g. VFCF_FUSE, and only match using are_fusefs() when the VFCF_FUSE flag is set on xvfsconf.

As it is implemented, it is too open-ended IMO.

[asomers]

lib/libc/gen/getvfsbyname.c

55

No, && is correct because strncmp and strcmp are validating different arguments. The purpose of the loop at line 81 is to match an actual file system's name with the name in a static list. But when using -o subtype, the filesystem's name won't be in the list. So are_fusefs matches something like fusefs.ext2 with the fusefs in the static list.

82

I don't understand your objection. Are you concerned that there's some scenario where are_fusefs will wrongly match?

[kib]

lib/libc/gen/getvfsbyname.c

55

I see, thank you for the explanation.

82

I am concerned that we add matching of vfc by regexp, while we can instead do it precisely without introducing a fuzzy logic.

But in fact getvfsbyname(3) has very limited usage. so ignore me.