Slight change of vnode<-->vm object relationship.

Poul-Henning Kamp phk at
Tue Jan 11 13:40:49 PST 2005

Today a vnode gets its vm object through an explicit call to
VOP_CREATEVOBJECT() and these calls are scattered all over the place
in code which shouldn't really have to know about this detail.

It seems to me that it would make much more sense to make it became
the responsibility of VOP_OPEN() and VOP_CLOSE() to manage the vnodes

First of all, it gets put into the filesystem which implements the
vnode, that's always cleaner, even if it just ends up calling a generic
function to do all the work.

But second, and from a buffer cache perspective far more important
reason: it makes the VOP_GETVOBJECT() call go away because the
vp->v_object pointer will be stable as long as the vnode is open.

The vp->v_object pointer is likely to be valid also after the vnode
has been closed, at least as long as there are cached pages in
RAM for the vnode, but again the vp->v_object pointer will tell
us that without a need to call down the stack of vnodes to find out.

For NULLFS/UNIONFS this works particular elegant:  on VOP_OPEN,
the lower vnods v_object is copied to the upper vnode (I don't even
think we need to grab a reference because we already have a reference
on the lower vnode anyway).  On VOP_CLOSE we simply zero the v_object
pointer on the upper vnode.  The lower vnode will still cache the
object and pages, and if we open again, all we have to do is copy
the pointer.

Anyone spot what I didn't ?

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

More information about the freebsd-arch mailing list