Subject: Re: removing VOPs
To: Jonathan Stone <jonathan@Pescadero.dsg.stanford.edu>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 09/27/2005 18:02:44
--z4+8/lEcDcG5Ke9S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 27, 2005 at 05:30:13PM -0700, Jonathan Stone wrote:
> In message <1127860302.790673.1659.nullmailer@yamt.dyndns.org>,
> YAMAMOTO Takashi writes:
>=20
> Once you start trying to make that work, I find that you very, *very*
> quickly break what should be clean abstraction boundaries between
> filesystem layers. =20

I'm not sure about this. I think part of the problem (and where it gets=20
messy) is that the file system interface is a lot more than the VFS and=20
VOP interfaces, yet they are the only ones that are adjusted with an eye=20
to layering. The UVM/UBC levels also need to be worked on with an eye to=20
layering and cache issues, yet haven't been.

> I'm not sure about that, either.  Before I tried to wrap my head
> around FiST, and UFS, and holes, and mmap() consistency, I'd have
> agreed with you. After my attempt, I'd prefer that we do our
> due-diligence and check whether serious attempt to build stackable
> filesystems really *do* end up needing to expose these nominally
> filesystem-internal APIs between stacked-filesystem layers.
>=20
> Is anyone who knows our vnode API really well (bill? chuck?) willing
> to volunteer?

I have looked a little at FiST, but not far enough. However I doubt that=20
these operations that Yamamoto-san is thinking about are anything that=20
FiST needs to deal with. Part of his whole point is that nothing outside=20
of the file systems themselves will make these calls, thus FiST will never=
=20
need to intercept them.

Take care,

Bill

--z4+8/lEcDcG5Ke9S
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDOeu0Wz+3JHUci9cRAjERAJ9nHZZibNRthET7CAUErIAawDtmqQCeINkq
UA3OdROM4BWh3nKbQR25M04=
=UKQl
-----END PGP SIGNATURE-----

--z4+8/lEcDcG5Ke9S--