Date: Fri, 18 Jan 2002 20:06:09 -0500 From: "Alexander N. Kabaev" <ak03@gte.com> To: Maxime Henrion <mux@sneakerz.org> Cc: freebsd-arch@freebsd.org Subject: Re: Proposal for a new mount API Message-ID: <20020119010608.GA98105@kanpc.gte.com> In-Reply-To: <20020118164457.B52542@sneakerz.org> References: <20020118112224.236b4754.ak03@gte.com> <12159.1011371137@critter.freebsd.dk> <20020118114124.61c39faf.ak03@gte.com> <20020118105335.A50775@sneakerz.org> <20020118144715.587a577c.ak03@gte.com> <20020118152920.A52542@sneakerz.org> <20020118172820.21f4e2b5.ak03@gte.com> <20020118164457.B52542@sneakerz.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Because if you can't use the void * pointer from the kernel (or with gross > hacks) you will resort to use the flags parameter. If you can be satisfied with a simple flag, nothing prevents you from simply adding corresponding field into <yourfs>_args struct and copyin whole struct at the mount time and even save it as a part of your private mount structure for future use. You could then reference fields of the structure directly whithout calling the new accessor function which is needed for new API. > We can tell if a parameter is safe to access as a string or not. The API > described in my original mail allows it very easily, though maybe a > vfs_getopt_string() that does the checks would be needed. How are you going to distinguish 32-bit integer 0x00202020 from " " on i386 unless you specifically mark it as integer somehow? > The advantage of retaining the mount options is because some code may > want to look at it. For example, Robert Watson recently told me that > the MAC code will be a consumer of mount options, this at execve() time. > > And it's good to discourage use of binary parameters because with a bit > of luck (if people cares) the noone will use them if they are not really > needed. Note that binary parameters in themselves don't ncecessarily > prevent us from being able to mount the fs in a generic way, they only > prevents it if this binary parameter is mandatory to the filesystem. Agreed. I was just arguing that all custom mount parameters going in and out of the kernel should preferably be strings for so that they safely can be included in a mount(8) output or read by automounter from a text map and then used to mount a new filesystem, for instance, even though neither mount(8) nor automounter have slightest idea what they actually mean. > There was examples in my original post that you apparently didn't read > entirely. If only that was so simple. Your example of recode tables is actually not representative. Custom loaded recode tables were supposed to be a temporary hack. Now, when libiconv is available as a kernel module, these filesystems should follow smbfs lead and use iconv instead. All they will need is to pass from/to charset names to use and let their mount programs to preload necessary conversion tables. If Linux managed to get by without binary parameters in mount then there is no reason we can't. All in all I am pretty much in favor of the new API. I just want the message about binary parameters not welcome to be stressed more strongly. Thanks for taking time to answer my questions. -- 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?20020119010608.GA98105>