Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jan 2001 00:37:42 +0100
From:      Adrian Chadd <adrian@freebsd.org>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: mount options
Message-ID:  <20010124003742.B863@roaming.cacheboy.net>
In-Reply-To: <20010123145902.F26076@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Jan 23, 2001 at 02:59:02PM -0800
References:  <20010123130628.A77423@hub.freebsd.org> <20010123145902.F26076@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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:
<adrian@freebsd.org>		   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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010124003742.B863>