From owner-cvs-src@FreeBSD.ORG  Tue Jan 25 09:28:26 2005
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id D66BA16A4CE; Tue, 25 Jan 2005 09:28:26 +0000 (GMT)
Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 2FFC943D39; Tue, 25 Jan 2005 09:28:26 +0000 (GMT)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0P9SLUB079411;
	Tue, 25 Jan 2005 10:28:21 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Jeff Roberson <jroberson@chesapeake.net>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Tue, 25 Jan 2005 04:24:18 EST."
             <20050125042317.D18864@mail.chesapeake.net> 
Date: Tue, 25 Jan 2005 10:28:21 +0100
Message-ID: <79410.1106645301@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
cc: cvs-src@FreeBSD.org
cc: src-committers@FreeBSD.org
cc: cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/kern imgact_elf.c kern_descrip.c
	kern_exec.c uipc_syscalls.c vfs_bio.c vfs_subr.c vfs_syscalls.c 
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2005 09:28:27 -0000

In message <20050125042317.D18864@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.

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.

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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@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.