From owner-freebsd-fs Fri Dec 17 11: 2:39 1999 Delivered-To: freebsd-fs@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 61FDD1576E for ; Fri, 17 Dec 1999 11:02:24 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 25B3F1C03; Sat, 18 Dec 1999 03:02:22 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: robert+freebsd@cyrus.watson.org, freebsd-fs@FreeBSD.ORG Subject: Re: Request for objections: extended attribute and ACL interfaces In-Reply-To: Message from Terry Lambert of "Fri, 17 Dec 1999 02:04:17 GMT." <199912170204.TAA08405@usr07.primenet.com> Date: Sat, 18 Dec 1999 03:02:22 +0800 From: Peter Wemm Message-Id: <19991217190222.25B3F1C03@overcee.netplex.com.au> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert wrote: > > Terry, > > > > First let me start by saying that I greatly appreciate your taking the > > time to send your comments--I value your feedback. Please see my comments > > below. > > > > > I personally have no objection to these interfaces. They seem to > > > cover the problem space that you say that they cover, and they are > > > at worst, harmless. > > > > The only functionality I'm not sure how to handle is identifying the > > attributes available on the file for the presence of duplication--where > > they back another file system visible object (such as ACLs, MAC labels, > > etc) then those interfaces should be used to back up the attributes. It > > isn't clear to me that attributes should be backed up independent of > > semantics available to interpret them, as they will most often be used for > > file system services where restoring them and associating them with the > > same file may not make sense, nor even be possible given the rights and > > functionality associated with what they back. I am comfortable not > > defining that behavior just now, and waiting to see what applications > > require it. I can also conceive of write-only attributes, etc. > > The reason I said "harmless" is rather deeper. > > The Heidemann framework supports the ability to add VOP's to an > existing system. FreeBSD doesn't currently support this, but it > could be fixed to do so, simply by making *vfs_op_descs[] a > pointer reference, and reallocating it as needed in order to > grow the descriptor list using loaded descriptors. Terry, why don't you freaking well *look* at the code every now and then? This *is* implemented and works already, for over a year now. kern/vfs_init.c: ---------------------------- revision 1.39 date: 1998/11/10 09:04:09; author: peter; state: Exp; lines: +223 -125 Make the vnode opv vector construction fully dynamic. Previously we leaked memory on each unload and were limited to items referenced in the kernel copy of vnode_if.c. Now a kernel module is free to create it's own VOP_FOO() routines and the rest of the system will happily deal with it, including passthrough layers like union/umap/etc. Have VFS_SET() call a common vfs_modevent() handler rather than inline duplicating the common code all over the place. Have VNODEOP_SET() have the vnodeops removed at unload time (assuming a module) so that the vop_t ** vector is reclaimed. Slightly adjust the vop_t ** vectors so that calling slot 0 is a panic rather than a page fault. This could happen if VOP_something() was called without *any* handlers being present anywhere (including in vfs_default.c). slot 1 becomes the default vector for the vnodeop table. TODO: reclaim zones on unload (eg: nfs code) ---------------------------- Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message