From owner-cvs-src@FreeBSD.ORG Fri May 26 14:03:33 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C18E16A426; Fri, 26 May 2006 14:03:33 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67DAA43D4C; Fri, 26 May 2006 14:03:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k4QE2wNW039073; Fri, 26 May 2006 08:03:03 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44770A91.50007@samsco.org> Date: Fri, 26 May 2006 08:02:57 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues References: <200605260121.k4Q1LqLd098354@repoman.freebsd.org> <44766E9B.6030000@samsco.org> <20060526033840.GA9864@crodrigues.org> In-Reply-To: <20060526033840.GA9864@crodrigues.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/udf udf_vfsops.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 14:03:35 -0000 Craig Rodrigues wrote: > On Thu, May 25, 2006 at 08:57:31PM -0600, Scott Long wrote: > >>So is it no longer possible for a filesystem to veto or otherwise >>massage an export request? > > > It is still possible. This is because vfs_export() is > only called in vfs_mount.c, only *after* the VFS_MOUNT() > call for an individual filesystem is called. > > An individual filesystem can check the mount options being passed into > its VFS_MOUNT() call, and do a vfs_getopt() and look for the > "export" option, which contains a "struct export_args", which is > eventually passed to vfs_export(). > > The specific filesystem can do: > (1) If the mount options passed into the specific filesystem's > VFS_MOUNT() call contains "export", the filesystem > can return an error from VFS_MOUNT() if it doesn't want to deal > with export requests at all. > The code in vfs_mount.c checks for the return status of VFS_MOUNT, > and if there is an error, it will *not* call vfs_export(). > > (2) If the mount options contains "export", the filesystem > can do a vfs_getopt(), manipulate the contents of the struct export_args, > then return 0 (for success). The code in VFS_MOUNT will > then call vfs_export(), passing in the same struct export_args > that the individual filesystem > > > One example of a filesystem vetoing an "export" request > is in fs/msdosfs/msdosfs_vfsops.c : > > if (vfs_flagopt(mp->mnt_optnew, "export", NULL, 0) { > /* Process export requests. */ > if ((pmp->pm_flags & MSDOSFS_LARGEFS) != 0) > return (EOPNOTSUPP); > else > return (0); > } > > > Most of the filesystem code I saw looked like they had > just cut-n-pasted their calls to vfs_export(), so it was > fairly easy to consolidate everything in one place, vfs_mount.c > > With my recent changes to mountd, to convert to nmount() and remove hardcoded > dependencies on ufs, cd9660, ntfs, and msdosfs, > it should be easier to export different filesystems from FreeBSD. > > For example, it should now be possible to NFS export an ext2fs > from FreeBSD. > Assuming that fhtovp, vptofh, vget, and cookies all work in ext2fs =-) Scott