Subject: VOP_SEEK / VOP_GETATTR attrocities/oddities
To: None <tech-kern@NetBSD.org>
From: Reinoud Zandijk <reinoud@netbsd.org>
List: tech-kern
Date: 09/21/2006 14:38:42
--gKMricLos+KVdGMg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Dear folks,

in my work on the SEEK_DATA/SEEK_HOLE lseek() extension i stubbled on the 
following:

Firstly:

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 is 
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 block 
device? On the other hand why is stat(3) working on a device node when 
spec_getattr is a ebadf ? Answer prolly: its not a specfs... but then i'm 
puzzled.

Secondly:

ufs/mfs/mfsnode.h:70:#define    mfs_seek        genfs_badop

Does this mean no seek's are possible on MFS? or is this entry overwritten 
by say UFS?

Puzzled,
Reinoud


--gKMricLos+KVdGMg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (NetBSD)

iQEVAwUBRRKHy4KcNwBDyKpoAQJ6jwgAtQcB7RfYoGhsgvtOZevzuxaNm+NBpbVa
GwdhsWqK7Ww3maRcMVIO5mbxC6/dA5ZQcOqbYc5+007XBRWfVDNAEHLyDBlCsWFi
JrDlAyAkrUORmQiDtEV4/okC5hpDDWHH44TzBFYHUtErgBYfkdkol3ij6XWfFp9m
OHYhXMsA+haGQkvaZ6u23vpsg3R0HX0baJUKCeF0dx9KbofowyUcwnOQTzEp2SlR
CSC5ncF2LQ6NCd8Uf/9DT0ti5tKyJ4+EB3WtH07TTkct2phZbl1LreawFfvxbnBW
Ga0yN8CC3Rn45pyukqD5C/jq/mE1PnxD8i06HMki7+c1UAYJ9QV16Q==
=KqtU
-----END PGP SIGNATURE-----

--gKMricLos+KVdGMg--