Factor out code from fstyp into libfstyp

[me_jamesrm.com]

Summary

Goal for this pr is to start the work involved to enable mount(8) to automatically detect
a partion type where possible. Factoring out the code from fstyp which does the filesystem
type detection will then make it available to mount(8) in a future submission.

I will add lib/libfstyp/fstyp.3 to this revision once the code/api/idea has been accepted.

Test Plan

I have compared the output of fstyp from this branch with the version installed from
13-current against a small subset of partitions I have on my machine (msdos, ntfs, zfs)

[kevans]

Throwing @trasz in here, he might be interested as the original author.

Tagging @freqlabs as a subscriber in case it looks like a shiny target for some lua bindings.

[kevans]

lib/libfstyp/Makefile

8

Can you throw in an fstyp(3) manpage here? lib/libbe/libbe.3 might be an ok-ish simple example

[trasz]

I'm not a huge fan of this, to be honest. Not the implementation, but rather the idea.

By turning this into library, you're losing the separation, in particular the sandboxing. You're also adding the overhead (more in terms of "how many moving parts there are in the system", not performance overhead) of additional system library.

The fstyp(8) utility is already designed to make other apps make use of it: just use popen(3), and then fscanf(3) the standard output.

[me_jamesrm.com]

Thanks for the feedback @trasz - I can see the argument for isolation - but shelling out introduces it's own problems. The APIs are implicit + can break without anyone noticing. If the output (API) of fstyp changes it's dependencies could break or exhibit undefined behaviour, and this will not be obvious to the person making those changes. Also consuming fstyp as a library makes it much easier to see it's dependencies, they are declared in the build files.

I have made a proof of concept using popen: https://github.com/JamesRM/freebsd-src/pull/2/files as a way compare the two options.

[cem]

I think the idea is very reasonable and could be done in a way that preserves the safety of the sandbox, at least for fstyp. I don't think the popen approach makes sense. There may be a lot of work required to sandbox the suggested consumer (mount).

[trasz]

If the output of fstyp(8) changed, it would break pretty much everything that uses it. Remember this utility was created for scripting.

However, looking at your other review (which makes use of popen), I've noticed an unexpected problem: to make it safe, you'd have to escape the path. That's one of the reasons why automount(8) uses it's own shell-less popen(3) replacement, although you might be able to do it using strvis(3) instead.

Another thing is, for small utilities like mount(8), libraries are expensive. If you really want to follow that route, how about integrating it into libutil?