From owner-freebsd-arch Thu Jan 17 15:35:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 1443137B416 for ; Thu, 17 Jan 2002 15:35:38 -0800 (PST) Received: by sneakerz.org (Postfix, from userid 1023) id 77CD25D006; Thu, 17 Jan 2002 17:35:32 -0600 (CST) Date: Thu, 17 Jan 2002 17:35:32 -0600 From: mux@sneakerz.org To: freebsd-arch@FreeBSD.org Subject: Proposal for a new mount API Message-ID: <20020117173532.A48367@sneakerz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, As you already know if you read the FreeBSD projects development status report, I've been working with Poul Henning-Kamp to design a new mount API. The text below explains the problems we are having with the existing API and how we intend to solve them with the new one. The new mount API intends to overcome some limitations of the existing API. The problem is how we pass data to the filesystems when mounting them. Right now we can have only 32 mount options because we use a bitmap to communicate them, along with a void * for some of the special cases. Some things which are really mount options, like the device name, are treated specially, while other mount options like quota information is not dealt with at all. With nmount, we have a generic way to pass an indefinite number of options to the filesystems, which are transferred in a struct uio. These options are uiomove()'d by the vfs_nmount() function, so we are able to pass these options from the kernel as well. We are not limited by the 32bits flags anymore, and it will help fixing problems with the export stuff and should greatly simplify the handling of quotas. From the filesystem point of view, we have two different functions to get the options : vfs_getopt() and vfs_copyopt(). The first one returns a pointer to the value of the option. This is probably only convenient for strings and fixed size types like integers and structs. The second one will copy the value of the option to a specified buffer, which fits more for binary data like the Unicode tables of msdosfs or, as we could imagine, cryptographic keys for some crypto fs. Here are the prototypes of these two functions : int vfs_getopt(struct vfsoptlist *opts, const char *name, void **buf, int *len); int vfs_copyopt(struct vfsoptlist *opts, const char *name, void *dest, int len, int *done); The exact behaviour of these functions is explained in the comments above their definition. The one special case to consider is MNT_UPDATE. The struct mount holds a pointer to another option list, only set in the mount update case. It allows the underlying filesystem to compare between the two lists of options and to behave accordingly. The vfs_nmount() function is not intended to be called directly from the kernel as the vfs_mount() function was. If we need to mount a filesystem inside the kernel, we have two wrappers for this purpose. Their prototypes are : int kernel_mount(struct iovec *iovp, unsigned int iovcnt, int flags); int kernel_vmount(int flags, ...); The iovec's of kernel_mount() are intended to be passed by pairs, the first one pointing to the name of the option and the second one to its value. The old const char *type and const char *path parameters are now passed as options as well. kernel_vmount() is a more convenient form of kernel_mount(), since it takes a NULL terminated list of strings of the form "name=value". Obviously, this can only be used with filesystems that don't require binary data. These two functions then both create the struct uio and call vfs_nmount(). From userland point of view, the prototype of the new mount syscall is identical to kernel_mount()'s one and we use it exactly the same way. int nmount(struct iovec *iovp, unsigned int iovcnt, int flags); Of course, we got rid of the void * parameter. It may be interesting to write a libc wrapper in the future if we want to have a kernel_vmount()-like call in userland. The code which implements this API is available at : http://www.sneakerz.org/~mux/mount.diff For the moment, filesystems that want to use the new mount API have to set their VFS_MOUNT function to NULL in the struct vfsops, and provide their new VFS_NMOUNT function which has been added at the end of struct vfsops. This allows the patch to be applied without hopefully breaking anything :-) Opinions, comments and advices are of course greatly appreciated. Maxime Henrion To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message