Bill Sommerfeld wrote:
> There are currently three levels of indirection for sockets:
> 	-> through f_ops->fo_* in sys_generic.c
> 	-> through so_{receive,send} in sys_socket.c
> 	-> through pr->pr_usrreq in uipc_socket.c
> 
> A "sockfs" or "sockvn" vnode type would collapse the first two into one.

And can't you collapse those first two into one if using struct fileops too?
soo_read() would call soreceive() directly.
It seems soo_read()/soo_write() only indirects through those two
because it has been believed to be necessary.
 
> We can tackle the others once we've sliced out this level of overhead.

Just curious, is there any (significant) overhead in using a fs/vnode
dispatch instead if current struct fileops? I mean, in cases like
the new pipe, when there is only one level of indirection anyway.

> Well, i believe there's another back-burner project to speed up the
> VOP_* dispatch (and turn VOP_* into macros) which would dovetail very
> nicely with this.

Good :)
 
> > Where would the locking happen? Directly in sys_read()/sys_write() ?
> 
> No, in VOP_READ/VOP_WRITE unless IO_NODELOCKED was set.

This sounds plausible. Is the lock protocol used by sockets
compatible with vnode locks?

Note I don't oppose the 'treat everything as a vnode' approach. If fs-type
dispatch serves us nicely, why use special-case fileops. I just wonder
if VOP_READ()/VOP_WRITE() is/can be as fast as direct indirection
through f_ops->fo_read.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!