From owner-freebsd-current Mon Oct 19 11:39:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA04929 for freebsd-current-outgoing; Mon, 19 Oct 1998 11:39:17 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA04923 for ; Mon, 19 Oct 1998 11:39:15 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA22615; Mon, 19 Oct 1998 11:38:49 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd022433; Mon Oct 19 11:38:34 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA00992; Mon, 19 Oct 1998 11:38:23 -0700 (MST) From: Terry Lambert Message-Id: <199810191838.LAA00992@usr02.primenet.com> Subject: Re: mount flags To: chuckr@mat.net (Chuck Robey) Date: Mon, 19 Oct 1998 18:38:23 +0000 (GMT) Cc: peter@netplex.com.au, nik@nothing-going-on.demon.co.uk, andyf@speednet.com.au, freebsd-current@FreeBSD.ORG In-Reply-To: from "Chuck Robey" at Oct 18, 98 11:30:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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