Add fstyp(8) utility. It's named after SVR4 utility which did something
similar. Plan is to use it for "-media" autofs map.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
I will look at this in a bit, but the first question is how does this differ from using file -s? There should also be a SEE ALSO entry for file(1).
Comment Actions
It differs in four ways: its output is machine-parseable, it supports labels, it doesn't know about non-filesystems, so won't get confused, and is secure, due to capsicum. Take a look at the -special autofs map in https://reviews.freebsd.org/D1210 - with this tool, all of the file/glabel ugliness goes away.
Comment Actions
I think this is fine, but do check with contrib's in-tree maintainer. The desire to avoid modifying contrib at all costs comes from CVS limitations which no longer apply.
| usr.sbin/fstyp/fstyp.c | ||
|---|---|---|
| 170–171 | I wonder if we should allow ENOSYS (and print a warning). | |
| usr.sbin/fstyp/msdosfs.h | ||
|---|---|---|
| 3–4 | Where does this file come from? Can we reuse msdosfs kernel headers instead? The reason I ask is that we're going to want msdosfs support in makefs(1), so the kernel headers in sys/fs/msdosfs/*.h will need to be available in userspace anyway. | |
| usr.sbin/fstyp/fstyp.c | ||
|---|---|---|
| 170–171 | Hm, you're right, but I'd prefer to not do a warning. I'll only annoy people; if someone builds kernel without capsicum, it's their fault, and their choice. In other words, I don't see a point in alarming people who disabled a feature that the feature is indeed disabled. | |
| usr.sbin/fstyp/msdosfs.h | ||
| 3–4 | It's from sys/geom/label/g_label_msdosfs.h. | |
Comment Actions
That's true.
I guess instead of a warning for this case (which has come up before) I'd like some way to choose in userland between "use capsicum if available" and "err if capsicum is not available." But I don't see a convenient way to do that.
Comment Actions
Don't fail on kernel built without capsicum, and add cross-references
from file(1) and mount(8). I've pinged brien@ whether he's ok with file(1)
change.
| usr.sbin/fstyp/msdosfs.h | ||
|---|---|---|
| 3–4 | Note that this file is quite different from what's found in sys/fs/msdosfs/. It is possible to merge the two, but I'd prefer to keep it in sync with geom_label, since that's where the code comes from. I could make it use kernel include instead of local copy, though. This would reduce code duplication, but would make it depend on kernel source tree. Hm. | |
| usr.sbin/fstyp/fstyp.8 | ||
|---|---|---|
| 53 | These are the names and capitalization of the filesystems as used on FreeBSD. Should the official names also be included when they differ? .Cm cd9660 | |
| 55 | s/The following/These/ | |
| 58 | The second comma is not needed. | |
| 63 | Passive -> active: s/will only work on/only works on/ Split sentence at "nodes" ...device nodes. | |
| 65 | s/undefinitely/indefinitely/ | |
| 70 | Second comma is not needed. | |
| usr.sbin/fstyp/fstyp.8 | ||
|---|---|---|
| 47 | s/Recognized/The recognized/ Remove comma. | |
| 55 | Based on the earlier explanation, add some explanation on how this utility is better for this purpose than file. Because | |
| 74 | Add: .Xr capsicum 4 , | |
Comment Actions
We should mention this project on an appropriate mailing list, perhaps freebsd-hackers?
| usr.sbin/fstyp/fstyp.8 | ||
|---|---|---|
| 47 | Looking at this again, "recognized" is redundant with the previous sentence, and can be removed. The comma after "output" is still not needed. | |
Comment Actions
Yeah, it should, although I'd probably like to see it go in as two commits if that's convenient. That will help others see how to libxo-ize something, and also make it easier to MFC.
Comment Actions
Not a hard requirement, but I think it's very valuable when we develop new tools to make use of recent tech additions to FreeBSD (e.g. capsicum, libxo).
It'd be great to get kyua tests here too.
Comment Actions
Not sure if it is too late or not, but this stuff would be perfect for fsck, mount and maybe others. Right now, we rely on the partition type to determine this (well, the GEOM attributes about the GEOM). this suggests that this should be a routine that is in a library and the fstyp command call into that library.
Comment Actions
The problem is, fstyp(8) depends on Capsicum, and if it were a library function, it would have to fork; otherwise the whole calling process would become sandboxed.