cvs commit: src/sys/kern imgact_elf.c kern_descrip.ckern_exec.c uipc_syscalls.c vfs_bio.c vfs_subr.c vfs_syscalls.c

[Jeff Roberson]

On Tue, 25 Jan 2005, Poul-Henning Kamp wrote:

> In message <20050125042317.D18864 at mail.chesapeake.net>, Jeff Roberson writes:
> >
> >On Tue, 25 Jan 2005, Poul-Henning Kamp wrote:
> >
> >> phk         2005-01-25 00:39:00 UTC
> >>
> >>   FreeBSD src repository
> >>
> >>   Modified files:
> >>     sys/kern             imgact_elf.c kern_descrip.c kern_exec.c
> >>                          uipc_syscalls.c vfs_bio.c vfs_subr.c
> >>                          vfs_syscalls.c
> >>   Log:
> >>   Don't use VOP_GETVOBJECT, use vp->v_object directly.
> >
> >How does this effect stacking?  Originally this was done so we could get
> >the appropriate level of vnode object.  Was this discussed somewhere that
> >I missed?
>
> It was discussed on arch@ recently.

Thanks, that was just what I was looking for.

>
> Short summary:  Instead of the code which calls VOP_OPEN being
> responsible for vnode_pager object creation it is now the vnode's
> own filesystem which must do so in vop_open() (and vfs_fhtovp() if
> exportable).  This also shaved 200 lines of code out.

Yes, the whole initialization step was pretty clunky.  This is definitely
an improvement.  Thanks.

>
> Stacking filesystems do this, for instance nullfs sets v_object to that
> of the lower filesystem in vop_open() and sets it to NULL in vop_close().
>
> That way vp->v_object can be used directly.

I think the original intention was such that you could have a translation
layer, and GETVOBJECT would return the translated stuff, while the
vnode's own private v_object would have untranslated stuff.  This will all
still be possible once the buffer cache works on bufobjs rather than
vnodes.  It was also never used, and probably never will be used, but I
believe that is the reason we didn't just use v_object before.

Cheers,
Jeff

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