Date: Thu, 26 Aug 1999 10:46:34 +0000 (GMT) From: Alfred Perlstein <bright@wintelcom.net> To: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Cc: hackers@FreeBSD.ORG Subject: Re: HEADS UP Reviewers. VFS changes to be committed. Message-ID: <Pine.BSF.4.05.9908261042480.6392-100000@fw.wintelcom.net> In-Reply-To: <199908261642.UAA07357@arc.hq.cti.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 26 Aug 1999, Dmitrij Tejblum wrote: > Just a few comments... > > > 2) The casting of VFS ops to eopnotsupp() has been removed and > > vfs_nop*() functions have been put into kern/vfs_default.c > > > > This makes it more clear that certain VFS-ops are giving default > > behavior, either returning automatic success or returning EOPNOTSUPP. > > I like the idea. (However, I think that the functions returning failure > should not be called NOPs.) What do you suggest? I'm flexible about this. > > > Why does VFS_CHECKEXP take a vnode and not a mount point? > > Hopefully in the future a filesystem will be able to more > > restrictively export its files, this will help facilitate that. > > IMO, if it take a vnode, it should be VOP_CHECKEXP, not VFS_CHECKEXP. #define VFS_VPTOFH(VP, FIDP) (*(VP)->v_mount->mnt_op->vfs_vptofh)(VP, FIDP) #define VFS_CHECKEXP(VP, NAM, EXFLG, CRED) \ (*(VP)->v_mount->mnt_op->vfs_checkexp)(VP, NAM, EXFLG, CRED) since i'm doing a lot of grunt work and would like to get it in, in a single commit what do you think of doing the same with VPTOFH? My only concern is that export-ability is more a VFS function than a vnode operation, even if the argument is a vnode. I'm not opposed to the work, it's just that there already exists a VFS_op that takes a vnode argument and my statement above about it being a function of the VFS. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9908261042480.6392-100000>