*BSD News Article 6757


Return to BSD News archive

Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!charon.amdahl.com!amdahl!paulp
From: paulp@uts.amdahl.com (Paul Popelka)
Newsgroups: comp.unix.bsd
Subject: Repeat of the question about VFS and VOP_SEEK()
Message-ID: <b3co03lsb3LE00@amdahl.uts.amdahl.com>
Date: 20 Oct 92 00:29:41 GMT
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 23


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?

Thanks,
Paul
paulp@sde.uts.amdhal.com