From owner-freebsd-arch Fri Jan 18 14:28:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from h132-197-179-27.gte.com (h132-197-179-27.gte.com [132.197.179.27]) by hub.freebsd.org (Postfix) with ESMTP id 09DCE37B402 for ; Fri, 18 Jan 2002 14:28:22 -0800 (PST) Received: from kanpc.gte.com (localhost [127.0.0.1]) by h132-197-179-27.gte.com (8.11.6/8.11.4) with SMTP id g0IMSKZ97550; Fri, 18 Jan 2002 17:28:20 -0500 (EST) (envelope-from ak03@gte.com) Date: Fri, 18 Jan 2002 17:28:20 -0500 From: Alexander Kabaev To: Maxime Henrion 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> Organization: Verizon Data Services X-Mailer: Sylpheed version 0.7.0claws8 (GTK+ 1.2.10; i386--freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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_ 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 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