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

[Poul-Henning Kamp]

In message <23763.1105479646 at critter.freebsd.dk>, Poul-Henning Kamp writes:
>
>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.

OK, with some input from various people, in particular kan@, I think
we have this stuff worked out:

The filesystems implementing a given vnode is responsible for
creating a vm_object for the vnode if it should have one.

This will happen in the following three entrances to the filesystem:

	vop_open()
		For regular files and directories.

	vop_lookup()
		For directories.

	vfs_fhtovp()
		For files and directories served via NFS.

Normal filesystems will call the (function currently known as)
vop_stdcreatevobject() in these three places.

For the layered filesytems (nullfs, umapfs, unionfs) the same
three places will just copy lowervp->v_object (possibly gaining
a reference ?) [1]

As a result of this, VOP_CREATEVOBJECT() is always an intra-filesystem
activity and will therefore be discontinued as a VOP.

VOP_DESTROYVOBJECT() will similarly be removed and instead filesystems
will be responsible for dismantling the vm_object in their vop_reclaim.
function.

VOP_GETVOBJECT() and VV_OBJBUF flags becomes unnecessary, instead
a NULL check on vp->v_object can be used.

Please shoot this down if you can spot flaws...

Otherwise keep an eye on p4://depot/user/phk/phk_bufwork/...

[1] I still don't think it will be possible to NFS-export unionfs
because we do not want to copy the lower file to the upper filesystem
until we know it is going to be written to, and that bit of information
is currently not availble from NFS since it is stateless. [2]

[2] There are other issues with unionfs as well.  I'm not promising
to fix it, but I'll try to keep it as functional as it is today.

-- 
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.