Date: Wed, 24 Jan 2001 00:47:25 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: adrian@FreeBSD.ORG (Adrian Chadd) Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mount options Message-ID: <200101240047.RAA05442@usr08.primenet.com> In-Reply-To: <20010123130628.A77423@hub.freebsd.org> from "Adrian Chadd" at Jan 23, 2001 01:06:28 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> I'd like to spark a discussion on the mount interface. It seems > a little evil right now, and I have noted that you can't add > arbitrary mount options through to an FS since they're passed > across as binary. Options which take a parameter should be recovered from "newfs", by looking at metadata stored on the FS itself. That's what the superblock is for. Options which don't take a parameter should probably be stuffed into a bitmap of 32 characters in length, which will cover all of ASCII. Argument parsing, other than boolean behaviour changes, really don't belong in the kernel. I think the NFS exports should be handled by NFS stat'ing, and reading, if it's changed, the /etc/exports file. I lean heavily toward an "exportfs" command, as exists on many OS, for triggering this, if a stat isn't feasible (but I think it is). I think the covered mount point is a seperate parameter, and I'd like to see the FS's not know about the difference between a root mount and a non-root mount: that should all be handed by higher level, common code. Right now the difference is: 1) Covering the mount point, if any 2) Adjusting the stored value of "last mounted on" 3) Hooking it into the mounted VFS list, so that a mount point traversal can be handled automatically If the mount VFSOP were split into one for "place this FS in the mounted VFS list", and a seperate one for "set the last mounted on and other metadata for this VFS" (only to be called upon non-root FS's), I think that most of the work involved in mount operations could be moved to common, upper level code. So the order of operation is actually 3, 1, 2, if you do it this way. You could actually go so far as to do #3 each and every time a device "arrives", automatically, assuming it had an appropriate class (e.g. a memory card for pictures, from a camera). > For an FS porting project I'm doing, the mount interface needs > to be able to export the mount options back out to userspace, > and I'd like to tidy the code up instead of just fudge it for > my needs. The bitmap would be ideal for this. The only arguments which would not fall into this are the "what you are mounting" and the "where you are mounting it" arguments, which will have to be handled seperately, in any case. For these arguments, I'd suggest passing it in by descriptor, just like the VOPS and VFSOPS work today. This will let you do things like pre-parse NFS host addresses in user space, by way of a covenant betweeen the user space fs-specific mount command, and the kernel space NFS client VFSOP for mounting (for example). > So, if you have an idea on how the mount interface *should* look, > now is the time to stand up and tell me what you're thinking.. :-) My two cents, anyway... 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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101240047.RAA05442>