From owner-freebsd-fs@FreeBSD.ORG  Fri Sep 12 18:27:24 2008
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 1B689106566B;
	Fri, 12 Sep 2008 18:27:24 +0000 (UTC) (envelope-from ed@hoeg.nl)
Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211])
	by mx1.freebsd.org (Postfix) with ESMTP id D6FCC8FC29;
	Fri, 12 Sep 2008 18:27:23 +0000 (UTC) (envelope-from ed@hoeg.nl)
Received: by palm.hoeg.nl (Postfix, from userid 1000)
	id D80D81CDCA; Fri, 12 Sep 2008 20:27:22 +0200 (CEST)
Date: Fri, 12 Sep 2008 20:27:22 +0200
From: Ed Schouten <ed@80386.nl>
To: FreeBSD FS <freebsd-fs@freebsd.org>,
	FreeBSD Arch <freebsd-arch@freebsd.org>
Message-ID: <20080912182722.GK1191@hoeg.nl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="sU4rRG038CsJurvk"
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Mark van Cuijk <mark@van-cuijk.nl>, Jille Timmermans <jille@quis.cx>
Subject: Expanding vops in vop_vectors during startup
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Sep 2008 18:27:24 -0000


--sU4rRG038CsJurvk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello everyone,

Yesterday I was talking with some friends of mine about the FreeBSD VFS
layer. As an exercise, Jille was trying to patch nullfs to hide .svn
directories (see hackers@), so that's how we got to the subject.

After talking about the way our vop_vector works (vop_bypass and
vop_default), we were wondering why we don't propagate all pointers in
the vop_vector to its children to save the unneeded function pointer
resolving inside the VOP_* calls.

I've created a patch that adds a new routine to the kernel,
vop_vector_init(), which recursively expands the vops. A new macro
(DECLARE_VOP_VECTOR) is used to automatically perform this when loading
modules/booting.

There is no need to reference default_vnodeops anymore, because it is
now used implicitly (when vop_vector =3D=3D NULL).

Any comments on the attached patch? I've only tested it with ufs,
nullfs, devfs, etc. yet. I haven't tested `make universe' yet, but I
suspect it shouldn't break hard.

URL:

	http://80386.nl/files/vnode-vop-expand.diff

Thanks!

--=20
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/

--sU4rRG038CsJurvk
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkjKtIoACgkQ52SDGA2eCwWsoQCeLhN84yU86WavBhgGnSLrxXs5
pTMAnR5LoTV8qUpLi2FxO38Hr5pw0Tak
=ALjF
-----END PGP SIGNATURE-----

--sU4rRG038CsJurvk--