Date: Fri, 06 Dec 2002 15:11:33 -0800 From: Peter Wemm <peter@wemm.org> To: "ouyang kai" <oykai@msn.com> Cc: hackers@FreeBSD.org Subject: Re: One Filesystem vnode operations declare problem. Message-ID: <20021206231133.C58392A7EA@canning.wemm.org> In-Reply-To: <F28Ypm7o8x6W5nEUpeY00015fc7@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"ouyang kai" wrote: > >From: Peter Wemm <peter@wemm.org> > >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. > I know in mi_startup(),the kernel will try to load the modules registered by > SYSINIT. I think its order is: firstly according 'sysinit_sub_id'; > secondly,if the 'sysinit_sub_id' are the same, it is accord > 'sysinit_elem_order', right? > I wonder if both of them is the same, the kernel will try to load which. > For example: > SYSINIT(nameA, SI_SUB_DRIVERS, SI_ORDER_FIRST, initA, NULL); > SYSINIT(nameB, SI_SUB_DRIVERS, SI_ORDER_FIRST, initB, NULL); > which do the kernel load firstly? Undefined. The bubble sort that orders these could leave it in any state. > > > >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. > union fs's means what? FreeBSD's UFS is result that union of UFS and FFS, > right? No, unionfs is a stacked file system. For example, you could create a read/ write layer stacked on top of a cdrom. This would allow you to create files which would end up in the top layer, but unmodified files could be read from the bottom layer. If you rm a file, a whiteout record gets created to make it appear that the file got deleted from the cdrom etc. Unfortunately, this works better in theory than in practice due to many layering problems in our kernel and VM system that are still work in progress. That is a whole different topic though. > >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. > Based on your words, I still do not understand those difference among those > VOP_SET. :(. I think your viewpoints is that the number of VOP_SETs and the > function of VOP_SETs is decided by the filesystem, right? I want to know the > general purposes of those VOP_SETs. > For example: in FFS: > VNODEOP_SET(ffs_vnodeop_opv_desc); I think it is normal operation vectors. > VNODEOP_SET(ffs_specop_opv_desc); I think it is special operation vectors. > But I do not know its purpose. > VNODEOP_SET(ffs_fifoop_opv_desc); I think it is FIFO operation vectors. > Why do those three VOP_SETs have many repeated defines? > Or All my thought is wrong? There is no VOP_SET. I think you mean VFS_SET(). This connects the file system itself to the kernel. VNODEOP_SET() connects the vnode descriptions to the kernel. ufs/ffs are a mini-filesystem-stack. ffs provides the on-disk infrastructure, while ufs is layered on top of it to provide name space. This is quite well hidden though and is mostly a behind-the-scenes thing. At one point there was a log structured file system that shared a lot of code this way. The file systems provide multiple operation vectors due to the way that device and named pipe nodes exist. For ufs/ffs, the actual connection point for /dev/ttyv0 (for example) lived on disk. When the user opened it, the file system would substitute the "normal" file based vectors for the specfs vectors. That way, the vnode would behave like a device. And the same goes for the fifo (named pipe) nodes. For FreeBSD 5.0, we have a seperate file system for /dev, so the specfs nodes in ufs/ffs are not normally used. But they do still work and are sometimes used for jail(8) environments. 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?20021206231133.C58392A7EA>