Date: Thu, 05 Dec 2002 23:19:24 -0800 From: Peter Wemm <peter@wemm.org> To: "kai ouyang" <oykai@msn.com> Cc: hackers@FreeBSD.org Subject: Re: One Filesystem vnode operations declare problem. Message-ID: <20021206071924.3BC1D2A7EA@canning.wemm.org> In-Reply-To: <F40M7e0C9guA8M6XQQe0000708b@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"kai ouyang" wrote: > Hi, everybody, > I have some questions about FS vnode operations. > I found the filesystems always declare vnode operations by "VNODEOP_SET" > more than once. > For example: > In DEVFS: > VNODEOP_SET(devfs_vnodeop_opv_desc); > VNODEOP_SET(devfs_specop_opv_desc); > In FFS: > VNODEOP_SET(ffs_vnodeop_opv_desc); > VNODEOP_SET(ffs_specop_opv_desc); > VNODEOP_SET(ffs_fifoop_opv_desc); > Why? Why can not the kerenel use only "devfs_vnodeop_opv_desc" or > "ffs_vnodeop_opv_desc"? > Another words, I want to know the difference among those "VNODEOP_SET" in > one filesystem. The name of the macro is a little strange, that is more of a historical relic where we used to declare these things in something called a 'linker set'. These days it is handled by a SYSINIT() function that registers the vnode ops. Our vnode op system is fully dynamic. We can create new VOP_xxx() functions on the fly. But for this to work, they need to be registered and assigned an index number in the system vectors. The act of referencing a "foo" vector in the xxx_opv_desc table adds support for a VOP_FOO(). For example, suppose we have some remote file system loadable module that supports remote file copies. That filesystem could introduce VOP_COPYFILE() that would cause the file to be copied on the server, rather than the source file being read by the client and then copied back to the new file. We could then load another module that adds a copyfile(2) syscall that calls VOP_COPYFILE(). And because of the vnode stacking system and the VOP_DEFAULT() vectors, we could even mount union fs's over the top of this hypothetical file system, even though at the time that unionfs was compiled there was no VOP_COPYFILE operation to pass down the stack. Quite a while ago, the kernel used to have a static list of supported VOP_* calls. This has not been the case for quite some time now. Any file system can create any VOP_* that it likes. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20021206071924.3BC1D2A7EA>