Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!caen!zaphod.mps.ohio-state.edu!swrinde!gatech!news.byu.edu!ux1!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Repeat of the question about VFS and VOP_SEEK()
Message-ID: <1992Oct21.201738.22999@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <b3co03lsb3LE00@amdahl.uts.amdahl.com> <1992Oct20.193544.2360@fcom.cc.utah.edu> <BwFu1E.759@pix.com>
Date: Wed, 21 Oct 92 20:17:38 GMT
Lines: 61
In article <BwFu1E.759@pix.com> stripes@pix.com (Josh Osborne) writes:
>In article <1992Oct20.193544.2360@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>[...]
>>I suspect that VOP_SEEK(), if it truly was intended to be called (which
>>I doubt; see my previous post) was intended to be implemented the same
>
>If the OS shouldn't call it, why does it exist?
Historical reasons?
An attempt at uniformity in VFS interfaces?
The author thought that there was a 1:1 correspondance between system calls
(like lseek) and VFS operations?
A lot of this same argument can be applied to the uniformity of the VFS
interface itself (or, really, the *lack* of uniformity). Why is the top
layer fairly well defined, but the bottom dependent on non-uniform kernel
support interfaces, instead of a uniform interface to the kernel support
interfaces? Why can't I just drop in the SVR4 VFS file systems?
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).
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.
For a better design definition, I'll refer you to:
"A Layered Approach to File system Development"
John S. Heidemann, Gerald J. Popek
Department of Computer Science
University of California, Los Angeles
Technical Report CSD-910007
March 1991
I diagree only on the interoperability and flow control implementation
issues brought forth in this paper, since I believe layer-based
redirection attributing can solve the variable stacking problems they
bring up, and I would like the ability to push different interdependant
subsystems without having to write glue routines (ie: a puchable NFS).
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------