On 07 Apr 2014, at 18:02, Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> wrote:
> Date: Mon, 7 Apr 2014 15:51:00 +0200 > From: "J. Hannken-Illjes" <hann...@eis.cs.tu-bs.de> > > On 07 Apr 2014, at 03:22, Taylor R Campbell > <campbell+netbsd-tech-k...@mumble.net> wrote: > >> Is the plan to nix getnewvnode and ungetnewvnode? It would be good to >> avoid long-term duplication of its body. But I suspect we'll want to >> keep those for, e.g., tmpfs, in which case this should use getnewvnode >> and ungetnewvnode instead of vnalloc/setup/teardown/vnfree. > > Not sure if we have to keep getnewvnode() in the long term. > > It cannot be used here as we don't want the partially initialised > vnode (before VFS_LOAD_NODE) on the mnt_vnodelist. > > If we end up replacing getnewvnode() with a two-stage allocator that > initialises in the first stage and finalises in the second stage we > may use it here. > > In that case, could you set the VI_CHANGING bit in vp, rather than > node->vn_vnode = NULL in the vcache node, to indicate that the vnode > is being initialized in vcache_intern? This will not work for layered file systems. They will share the v_interlock from another vnode (in VFS_LOAD_NODE) so we better don't use the interlock before loading the fs node. >> Does anything use VFS_VGET in ufs now? If so, why? If not, this >> should just fail. (Eventually we ought to nix VFS_VGET, I think.) > > VFS_VGET() is used by NFS V3 readdirplus so we have to keep it. > > Ugh bletch. OK for now, but it would be nice if there were a better > way to do this. > > Perhaps we ought at least to change VFS_VGET so it returns the vnode > unlocked, and once we do that, use it consistently to look up vnodes > by inode number rather than calling vcache_intern in multiple > different places. Maybe in the far future. Already looked at it and it is a very big job if we want to do it in one step. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
