Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Jan 2002 17:28:20 -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:  <20020118172820.21f4e2b5.ak03@gte.com>
In-Reply-To: <20020118152920.A52542@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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.

> 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?

> 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? 

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?20020118172820.21f4e2b5.ak03>