Subject: Re: VOP_SEEK / VOP_GETATTR attrocities/oddities
To: None <tech-kern@NetBSD.org>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 09/21/2006 09:17:48
Content-Type: text/plain; charset=us-ascii
On Thu, Sep 21, 2006 at 02:38:42PM +0200, Reinoud Zandijk wrote:
> Dear folks,
> in my work on the SEEK_DATA/SEEK_HOLE lseek() extension i stubbled on the=
> miscfs/specfs/specdev.h:111:#define spec_getattr genfs_ebadf
> miscfs/specfs/specdev.h:123:#define spec_seek genfs_nullop
> wich i changed to :
> miscfs/specfs/specdev.h:123:#define spec_seek genfs_seek
> to not alter its behaviour.
> However, all lseek(fd, 0, SEEK_END) and the likes fail for the size that =
> requested by spec_getattr() is a bad op. Shouldn't spec_getattr() get its=
> own function that does recognize its size and make up a profile for a blo=
> device? On the other hand why is stat(3) working on a device node when=20
> spec_getattr is a ebadf ? Answer prolly: its not a specfs... but then i'm=
UTSL. If you run gid on spec_getattr, you will find that it is only used=20
by spec_vnops.c, which has the following comment:
* This vnode operations vector is used for two things only:
* - special device nodes created from whole cloth by the kernel.
* - as a temporary vnodeops replacement for vnodes which were found to
* be aliased by callers of checkalias().
* For the ops vector for vnodes built from special devices found in a
* filesystem, see (e.g) ffs_specop_entries in ffs_vnops.c or the
* equivalent for other filesystems.
To be honest, I see no reason to change this.
> ufs/mfs/mfsnode.h:70:#define mfs_seek genfs_badop
> Does this mean no seek's are possible on MFS? or is this entry overwritte=
> by say UFS?
This means that seeks aren't possible ON THE MFS NODE, which is the node=20
used as a block device for the mfs file system. No seeking is needed on=20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----