Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Jan 2002 14:47:15 -0500
From:      Alexander 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:  <20020118144715.587a577c.ak03@gte.com>
In-Reply-To: <20020118105335.A50775@sneakerz.org>
References:  <20020118112224.236b4754.ak03@gte.com> <12159.1011371137@critter.freebsd.dk> <20020118114124.61c39faf.ak03@gte.com> <20020118105335.A50775@sneakerz.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Maxime,

are parameters in iovec supposed to be strings only, or you plan to
allow arbitrary binary data?  

  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. 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. The proposed API does not allow that
unless you require all the parameters in iovec to be strings. 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 :(--
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?20020118144715.587a577c.ak03>