Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!mcsun!Germany.EU.net!unidui!flyer!flatlin!bad From: bad@flatlin.ka.sub.org (Christoph Badura) Subject: Re: Repeat of the question about VFS and VOP_SEEK() Organization: Guru Systems/Funware Department Date: Sat, 24 Oct 1992 00:56:22 GMT Message-ID: <BwLp9z.8J2@flatlin.ka.sub.org> References: <b3co03lsb3LE00@amdahl.uts.amdahl.com> <1992Oct20.193544.2360@fcom.cc.utah.edu> <BwFu1E.759@pix.com> <1992Oct21.201738.22999@fcom.cc.utah.edu> Lines: 29 In <1992Oct21.201738.22999@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >A lot of the differences are evolutionary rates differring between systems, >and different choices being made (SVR4 seperate vop_read and vop_write >out of the BSD vop_rdwr for POSIX compliance and to avoid a recursion >loop, for instance). How could separating vop_rdwr into vop_read and vop_write help POSIX compliance. I'd be very interested in an explanation that takes into account that the SVR4 ufs-vop_read and ufs-vop_write almost instantaneousley call ufs_rwip. >Thus perhaps the best answer is that the interface is ill defined. In >the previous post referenced above, I referred to the illogicality of >making the call, since a seek offset is an artifact of an open file >descriptor, and is not an attribute of an inode or vnode in most of >the current implementations. I also pointed out a potentially valid use >for passing the seek down: predictive read ahead. The problem here is >that either the read, the seek, or the open would have to be attributed >to flag the descriptor for predictive behaviour if this is to be a >successful optimization. Since all that is needed for predictive read ahead below the VFS layer is a) a vnode and b) the new seek offset, I can't follow you illogicality claims. -- Christoph Badura --- bad@flatlin.ka.sub.org AIX is a better... is a better... is a better... OpenSystem. IBM Rep at GUUG Symposium '92