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