Subject: Re: making all fd's point at vnodes?
To: None <tech-kern@netbsd.org>
From: Jaromír <jdolecek@netbsd.org>
List: tech-kern
Date: 06/17/2001 22:20:41
> So, we currently have two levels of dispatch in the read/write path
> before we get to the "meat": there's  descriptor type dispatch, which
> until recently was just "socket" vs "vnode" (and we just got
> DTYPE_PIPE, and kqueue's are coming, too); then, we hit the
> descriptor-type dispatch routine which turns around and does *another*
> level of dispatch based on the socket or vnode type.

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.

> I think it makes sense to flatten these layers together.  as a first
> cut, this would involve:
>  1) make file->f_data into a "struct vnode *"
>  2) nuke "struct fileops" entirely
>  3) mutate kern/sys_socket.c into "sockfs"; likewise for the new pipe
> implementation and kqueues.  (sockfs would *not* be mountable; it
> would be an internal vnode implementation similar to specfs or
> deadfs).

My concern is - what exactly would you gain by this? 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.

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.

>  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() ?

>  5) nuke "ioflag"'s separate flag space; instead, merge the IO_* flags
> into the same flag space as the F* and O_* flags..
> (looks like the only "new" ones are IO_NODELOCKED and IO_UNIT;
> IO_APPEND==FAPPEND==O_APPEND, IO_SYNC==FFSYNC==O_SYNC,
> IO_NDELAY==FNONBLOCK, IO_DSYNC==FDSYNC|FRSYNC==O_DSYNC|O_RSYNC, and
> IO_ALTSEMANTICS==FALTIO==O_ALT_IO)

This is definitely good thing and should happen in any case.

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!