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!