From owner-freebsd-arch Tue Jan 23 15:38:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id F113137B69F for ; Tue, 23 Jan 2001 15:37:53 -0800 (PST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f0NNbgi01406; Wed, 24 Jan 2001 00:37:42 +0100 (CET) (envelope-from adrian) Date: Wed, 24 Jan 2001 00:37:42 +0100 From: Adrian Chadd To: Alfred Perlstein Cc: freebsd-arch@freebsd.org Subject: Re: mount options Message-ID: <20010124003742.B863@roaming.cacheboy.net> References: <20010123130628.A77423@hub.freebsd.org> <20010123145902.F26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010123145902.F26076@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Jan 23, 2001 at 02:59:02PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 23, 2001, Alfred Perlstein wrote: > I haven't thought about it much except how bad the interface is. Hah. :) > Just some random thoughts on it. :) > > I would think that simply using a string passing method given some > helper functions should be enough. There's really no effeciency > problem as I can see because this wouldn't restrict the VFS from > caching the information in a flags structure. At the same time it > could allow for extracting some form of the mount options in the > form of strings, perhaps a list of NULL terminated strings as a > large block (sysctl or fetch syscall could specify the block length)? > > I also think that passing in each option shouldn't depend on formatting > characters for seperation such as ',', instead it should be a list > of null terminated strings and a length of the block. I'm thinking something like this - but I was thinking about an array of sbufs per mountpoint containing the mountpoint options. Linux has a bunch of functions which manipulate the mount table and one of them gets a given mount option. This would be rather useful, both in kernel and user space. It also means that if the user decides to remount a filesystem and change the FS options (which is entirely possible, and we should provide the flexibility for each FS to support or not support this) then the options get updated correctly rather than "replaced" with the new set. > Some conventions might be in order, but the current async/noasync > atime/noatime stuff seems to work pretty well. Yup. Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message