> Well, two only for vnode/socket path, not for pipes. In the socket
> case, that second level of indirection is ~necessary and would be
> there even if fp->f_data would be a vnode.

Currently soo_read and soo_write indirect through so->so_receive and
so->so_send, but I can find *nothing* (and i mean *nothing*) in our
kernel which sets so->so_receive and so->so_send to anything other
than soreceive and sosend.

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.

> My concern is - what exactly would you gain by this? 

Reduced dispatch overhead, reduced stack depth, etc.,

> By this, you'd optimize the vnode path. The socket/pipe path would
> still have same number of levels of indirection as before.  My
> understanding is that vnode i/o path is the last thing which needs
> optimization from those three file descriptor code paths.

We can tackle the others once we've sliced out this level of overhead.

> The cons of your proposal is that you'd now need to implement pseudo fs
> for this, and push VOP_READ()/VOP_WRITE() semantics to sockets/other, including
> extra vop_{read|write}_args on stack, of course.

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.

> >  4) tweak the VOP_READ() and VOP_WRITE() function signatures (to
> > resemble the current vn_read signature), eliminating the flag and lock
> > juggling done at the vn_read() level.
> 
> Where would the locking happen? Directly in sys_read()/sys_write() ?

No, in VOP_READ/VOP_WRITE unless IO_NODELOCKED was set.

					- Bill