Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Dec 1999 03:02:22 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        robert+freebsd@cyrus.watson.org, freebsd-fs@FreeBSD.ORG
Subject:   Re: Request for objections: extended attribute and ACL interfaces 
Message-ID:  <19991217190222.25B3F1C03@overcee.netplex.com.au>
In-Reply-To: Message from Terry Lambert <tlambert@primenet.com>  of "Fri, 17 Dec 1999 02:04:17 GMT." <199912170204.TAA08405@usr07.primenet.com> 

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991217190222.25B3F1C03>