Date: Mon, 19 Oct 1998 18:38:23 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: chuckr@mat.net (Chuck Robey) Cc: peter@netplex.com.au, nik@nothing-going-on.demon.co.uk, andyf@speednet.com.au, freebsd-current@FreeBSD.ORG Subject: Re: mount flags Message-ID: <199810191838.LAA00992@usr02.primenet.com> In-Reply-To: <Pine.BSF.4.05.9810182323290.348-100000@picnic.mat.net> from "Chuck Robey" at Oct 18, 98 11:30:58 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > vfc_typenum is the same as the statfs.f_type field. That's how you match
> > them.
> >
> > You can, however, do a getvfsbyname("nfs") and get the magic number from
> > the returned vfc_typenum and use that instead of the old MOUNT_NFS
> > constant if that's more convenient. Beware that this isn't guaranteed to
> > remain constant in the face of vfs loads and unloads via the lkm or kld
> > mechanism.
>
> If I do the getvfsbyname method, I do no pattern-matching at all
> (FreeBSD does that for me). When I do the lookup, the data is good at
> that point, isn't it, even in the face of the vfs or KLD loads/unloads,
> right? And, as long as I do no dismounting (the fs is up) that number
> can't change on me. The *set* of available numbers and their mappings
> can change, but not the one I'm sitting on, right?
>
> If that's true, for my app, that will do.
The number can change if you load and unload modules, however.
To be as robust as possible, you should call getvfsbyname() before
every comparison. You *could* wrap this the same way errno is
currently wrapped, giving you a tiny glue function.
> I'd stop doing that, if I trusted that the statfs f_fstypename was
> reliably being set. It's too new, and I haven't found where it's
> getting set, no matter how much I search for it.
It's getting set in the file /usr/src/lib/libc/gen/getvfsent.c from
SYSCTL data.
Note: the current libc code tries to cache a list; this means that
using getvfsbyname is unreliable in the face of list changes as a
result of module manipulation. Someone should fix this.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810191838.LAA00992>