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: Repeat of the question about VFS and VOP_SEEK()
Message-ID: <1992Oct27.184748.24377@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <BwLoyL.85z@flatlin.ka.sub.org> <1992Oct25.113428.26098@fcom.cc.utah.edu> <Bwr6J7.7q1@flatlin.ka.sub.org>
Date: Tue, 27 Oct 92 18:47:48 GMT
Lines: 50
In article <Bwr6J7.7q1@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes:
>In <1992Oct25.113428.26098@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>
>>In article <BwLoyL.85z@flatlin.ka.sub.org>, bad@flatlin.ka.sub.org (Christoph Badura) writes:
>>|> In <1992Oct20.193544.2360@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>>|> >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).
>>|>
>>|> EBADFD is reserved for an invalid file descriptor beeing passed to a
>>|> system call (as opposed to EINVAL).
>>|>
>>|> EOPNOTSUPPORT would be more appropriate for obvious reasons.
>
>>The majority of ioctl() failures in VFS filesystem implementations return
>>ENOTTY, clearly improper. I would prefer that ENOTTY be used (however bogus
>>it would would be, since a special device may indeed be a tty, and some special
>>devices are seekable), since EOPNOTSUPP (which you probably meant instead of
>>"EOPNOTSUPPORT", which does not exist in /usr/include/sys/errno.h) clearly
>>refers to socket I/O ("Operation not supported on socket").
>
>EOPNOTSUPP (Yeah, I have to look it up every time.) was introduced
>with the networking support in BSD. But I find it more descriptive
>than ESPIPE, which is *the* traditional way to say that you can't
>lseek on a fd. So we're stuck with it.
>
I think the perror() from either of these would be more beffudling than
the one from the EINVAL.
>I don't see how ioctl(2) comes into play.
I suggested it as an operation which demonstrates the current mechanism
for handling a file system operation on an illegal fd for the operation,
and include it for illustrative purposes only. I still vote for EINVAL,
especially since I will make EOPNOTSUPP go away if I can ever get currents
or x-kernel up.
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
-------------------------------------------------------------------------------