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>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020117173532.A48367>