Date: Fri, 18 Jan 2002 16:44:57 -0600 From: Maxime Henrion <mux@sneakerz.org> To: freebsd-arch@freebsd.org Cc: Alexander Kabaev <ak03@gte.com> Subject: Re: Proposal for a new mount API Message-ID: <20020118164457.B52542@sneakerz.org> In-Reply-To: <20020118172820.21f4e2b5.ak03@gte.com>; from ak03@gte.com on Fri, Jan 18, 2002 at 05:28:20PM -0500 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Kabaev wrote: > I do not see what 32bit restriction and inability to call vfs_mount from > kernel space have in common. The new API clearly does not solve 32-bit > flags problem, as no such problem really existed. It just provides more > elegant way of doing what practically each filesystem has done on its > own before. Because if you can't use the void * pointer from the kernel (or with gross hacks) you will resort to use the flags parameter. Now that we have an easy way to pass an indeterminate number of options, from the kernel or from userland, we don't care about this flags parameter being only 32bits. > It was possible to use ugly stackgap hack to call vfs_mount from kernel > before. The new method is obviously infinitely more elegant. That is the > only advantage of the new API I see so far. Yes, using stackgap would be a gross hack IMO. > > Moreover, mount options are now retained in the mountpoint, and it > > will be possible to retrieve them any time. This wasn't the case > > before as well. > Almost every filesystem in the tree has arg_<fstype> struct as the first > member of its private mount structure. If parameters can only be decoded > by the filesystem itself, what is advantage of keeping it in > FS-independent mount struct? What good is in discouraging binary > parameters if you cannot tell beforehand which parameter is safe to > access as a string and which is not? 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. 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. > > > Which version of Linux are you talking about ? Linux 2.2 has a void * > > and I thought this didn't change in Linux 2.4. > It did not, but all filesytems in Linux kernel simply treat it as a > string, containing comma-separated options from the mount -o <optlist> > command. > > > Which explains why we discourage the use of these binary parameters. > > However, there are still cases where they are needed, so we can't go > > without them. > Could you please provide an example of such option? Is it absolutely > necessary to keep in binary? There was examples in my original post that you apparently didn't read entirely. Cheers, Maxime 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?20020118164457.B52542>