From owner-freebsd-current@FreeBSD.ORG Tue Jun 3 22:39:09 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A573137B401; Tue, 3 Jun 2003 22:39:09 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id F069143F3F; Tue, 3 Jun 2003 22:39:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfk3b.dialup.mindspring.com ([165.247.208.107] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19NQzE-0006c3-00; Tue, 03 Jun 2003 22:39:01 -0700 Message-ID: <3EDD85AD.FAFE1CED@mindspring.com> Date: Tue, 03 Jun 2003 22:37:49 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Richards References: <20030602014757.GA99626@perrin.int.nxad.com> <3EDB6A6F.827B7C22@mindspring.com> <20030602160411.GA24490@perrin.int.nxad.com> <20030603134717.GD35187@survey.codeburst.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d8b999ca45166bde500b87bcf1475605666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c cc: Hiten Pandya cc: current@FreeBSD.ORG cc: des@FreeBSD.ORG Subject: Re: VFS: C99 sparse format for struct vfsops X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2003 05:39:09 -0000 Paul Richards wrote: > On Mon, Jun 02, 2003 at 09:04:11AM -0700, Hiten Pandya wrote: > > And how many times is vfc_register() called? Its not in the > > patch of an I/O operation or anything. Its just a mount time > > overhead which will go through -- a one time thing. > > > > On Mon, Jun 02, 2003 at 08:17:03AM -0700, Terry Lambert wrote: > > > Consider this going forward: someone adds a new VFSOP to the > > > list of allowable VFSOPs, and the vfs_init() doesn't have any > > > specific code for it. > > You should look at kobj, it's precisely this sort of dynamic > dispatching that it was designed to support. I think it's inappropriate technology for the VFSOP and VOP cases. The real issue with VFSOP and VOP calls is that they are call-by-descriptor, and the descriptor reference can be proxied across a protection domain, no problem, as long as there are not weird defaults. For example, with a proxy in and out of the kernel of a top and bottem end named pipe/socket/other datia serialization interface, it's possible to do VFS stacking layer develeopement in user space, where there are better debugging tools, and where a failure is not fatal to the kernel. That means that the developement can proceed much rapidly from prototype to the finished product. It's also possible to proxy over a network; this provides a means of implementing an extensible network file system framework (like that which was prototyped by John Heidemann's students) to implement operations, as needed. One of the widely acknowledged weaknesses of NFS is it's inability to be meaningfully extended for things like extended attributes, ACLs, mandatory access controls, etc. -- all things requiring VFSOPs or VOPs to to b added to the protocol, structures defined, agreed upon by both parties, etc., etc.. With the descriptor mechanism, I may pass from the system call interface to a quiota stacking layer on a local machine, to a crypto stacking layer on a border machine, over the Internet, to a crypto layer on another border machine at the remote site, to a local machine at the remote site, and then down to FFS and from there to a local disk array. Not only that, the middle layers don't have to know all the VOPs descriptors, because they pass them through unmolested, and so the border machines are unaware of how to decode the content they are transiting. I really can't do this with kobj; with kobj, I can only pass the interface references around within a single protection domain on a single machine. -- Terry