Date: Fri, 18 Jan 2002 15:29:20 -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: <20020118152920.A52542@sneakerz.org> In-Reply-To: <20020118144715.587a577c.ak03@gte.com>; from ak03@gte.com on Fri, Jan 18, 2002 at 02:47:15PM -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>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Kabaev wrote: > Maxime, > > are parameters in iovec supposed to be strings only, or you plan to > allow arbitrary binary data? As Poul already stated, binary data is allowed, but discouraged. > > I apologize for being skeptical, but I fail to see what the new mount > API in its current form improves upon existing implementation if > arbitrary binary data will be allowed in parameters. Each and every FS > in the tree today uses void *args to pass FS-specific structure as an > argument to mount(2) syscall and is effectively able to work around the > 32-bit flags restriction, so iovec with binary data within is just > another way to repackage the same FS-specific structure. No, it's not another way to repackage the structure. The iovec's are then put in a struct uio and uiomove()'d, so now we can access this FS-specific structure from the kernel as well using the kernel_mount() wrapper. This wasn't possible before, that's why this 32bits flags restriction was annoying. 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. > User-land > programs will still be required to have intimate knowledge about what > parameters and in what exactly format (binary? struct? string? int?) > given FS requires on mount. In Linux, in contrast, a single 'mount' > binary is able to mount most available FS-es in uniform way, because it > simply passes parameters as strings to the kernel and allows each > individual FS to process them. 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. > The proposed API does not allow that > unless you require all the parameters in iovec to be strings. 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. > Even then > each FS still has to perform its own parameter parsing even for simplest > parameters. Common library of convenience functions to fetch parameter > value possibly converting it to desired type from string format could > take care of that. Do we want such functionality in the kernel? I asked > this question before but nobody has responded so far :(-- This may be reasonable. 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?20020118152920.A52542>