Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: A question about VFS and VOP_SEEK()
Message-ID: <1992Oct19.215718.17679@fcom.cc.utah.edu>
Keywords: bsd 4.3 vfs
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <9bek03AGb30Z00@amdahl.uts.amdahl.com>
Date: Mon, 19 Oct 92 21:57:18 GMT
Lines: 60
In article <9bek03AGb30Z00@amdahl.uts.amdahl.com> paulp@uts.amdahl.com (Paul Popelka) writes:
>I'm writing a filesystem for bsd 4.3 and have discovered that
>the seek entry point does not get called when the user does
>an lseek() system call. I looked at the lseek code in vfs_syscalls.c
>and found that it does not call VOP_SEEK() which would call
>my filesystem's seek entry point. I could not find any place
>where VOP_SEEK() or (*xx->vop_seek)() is called from within the
>kernel. So, I added a call to VOP_SEEK() into lseek() in
>vfs_syscalls.c. This caused a panic in spec_badop() which is
>what spec_seek() calls directly. So, some filesystems are not
>prepared to have their seek entry points called.
>
>So, my questions are: Should a filesystem's seek entry point be called?
>If so, from where? Should I just fix lseek() to call VOP_SEEK()
>and fix spec_seek() and any other filesystem seek entry points
>to just return success, instead of panic'ing?
I think this boils down to:
1) What does lseek() do?
2) Should VOP_SEEK() ever be called? When?
The first is easy to explain: lseek() is provided to allow calls to read()
and write() be relative. It modifies the contents of the seek offset
location for the file descriptor in question (fd):
cp->p_fd->fd_ofiles[ fd]->f_offset
This offset is then used in the implementation of read() and write().
The second requires some thought. Is there ever an occasion when you
want to know the seek offset has been set in order to predict a read
or a write? The answer is a tenative "yes". Most likely, this would
be done as part of a predictive read-ahead for "large access" files
(like executables) on a network server.
If you don't have a predictive reason to know in the FS when n lseek()
occurs, then you probably don't need to call the fs seek routine; the
offset will be given you for the read and write routines as part of the
I/O request context.
PS: The "fileops" structure in sys/file.h is stupid; it should be a
"struct vnode *".
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
-------------------------------------------------------------------------------