Differential D26743
Factor out code from fstyp into libfstyp Authored by me_jamesrm.com on Oct 11 2020, 9:36 PM. Tags None Referenced Files
Details Goal for this pr is to start the work involved to enable mount(8) to automatically detect I will add lib/libfstyp/fstyp.3 to this revision once the code/api/idea has been accepted. I have compared the output of fstyp from this branch with the version installed from
Diff Detail
Event Timeline
Comment Actions 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. Comment Actions 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. Comment Actions 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). Comment Actions 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? | ||||||||||||||||||||||||||||||||||||||