Date: Fri, 18 Jan 2002 11:12:46 -0500 From: Alexander Kabaev <ak03@gte.com> To: mux@sneakerz.org Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal for a new mount API Message-ID: <20020118111246.55725cdd.ak03@gte.com> In-Reply-To: <20020117173532.A48367@sneakerz.org> References: <20020117173532.A48367@sneakerz.org>
next in thread | previous in thread | raw e-mail | index | archive | help
int nmount(struct iovec *iovp, unsigned int iovcnt, int flags); According to the folowing prototype, you are planning to pass standard mount options through flags. This will limit you to max 32 standard mount options on 32-bit platforms. What people think about getting rid of the flags parameter and passing standard mount options in the same way as other parameters using their string representations such as ro/rw? We could implement analog of getmntopts in kernel space to reconstruct binary MNT_XXX flags for internal use and in to save some space in memory. As far as I understand, you allow parameters to be passed as binary blobs. I think adding verbose output to the mount(8) command to list all the options active on given mount point is a desirable feature and the new API should make provisions for that. Hopefully, mount(8) should use single generic API to fetch all the options currently in effect from the mounted FS, no matter what the FS type is. Binary blobs, which only particular FS is able to understand, are not making adding this feature any easier. May be we should allow FSes to register description of the parameters and types they understand with the new mount subsystem and change proposed API to pass name, type and value instead of just name/value pair for each parameter to the syscall. This way, filesystems writes will be able to use function calls like int vfs_getopt_int(opts, "mask", &mask) to fetch the integer parameter. New mount code wil match the requested type with the type in syscall parameter list and do necessary conversion, if possible. The existing netgraph code could be used for a conversion between binary types and strings. This will also allow programs such as amd to use generic code to mount any filesystem type. It will just pass all parameters defined in the map entry as strings and the new mount syscall will present these parameters to FS in the form it expects. Just my $0.2 -- Alexander Kabaev 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?20020118111246.55725cdd.ak03>