*BSD News Article 6803


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!pmafire!mica.inel.gov!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: <1992Oct20.193544.2360@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <b3co03lsb3LE00@amdahl.uts.amdahl.com>
Date: Tue, 20 Oct 92 19:35:44 GMT
Lines: 48

In article <b3co03lsb3LE00@amdahl.uts.amdahl.com> paulp@uts.amdahl.com (Paul Popelka) writes:
>
>I've posted this once but said something misleading.  I said
>bsd 4.3 when I meant net-2/386bsd.  I'll try again.
>
>I'm writing a filesystem for 386bsd 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 file 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 file 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 vote that spec_badop() shouldn't cause a panic; this is possibly a
result of not checking the return value if VOP_SEEK() in lseek().

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
way VOP_OPEN() is implemented: as a veto on the operation by specific
file system type.  I suspect this is what should be happening when you
seek on a special device... the lseek should return a -1 with errno
set to EIO/EINVAL/ESPIPE/EBADFD (EINVAL seems most reasonable).

I still question the utility of causing the seek to do something other than
what it is intended to do, which is to set the offset in the struct file
for the fd lseek()'ed on, unless you are involved in a predictive read
operation (such as on a file server).


					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
-------------------------------------------------------------------------------