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

On Mon, Apr 05, 2004 at 12:04:25PM +0900, YAMAMOTO Takashi wrote:
> > My objection to your suggestion of having each fs roll its own is that =
we=20
> > have five routines doing the same thing (local fs's) and four routines =
all=20
> > doing the same thing (remote fs's) different from the first thing. We h=
ave=20
> > nine routines working out two behaviors.
> >=20
> > It sounds both cleaner and easier to maintain to just have those routin=
es
> > either call one of two common routines, or call one common routine that
> > supports the two behaviors.
>=20
> what routines are you talking about?
>=20
> did you read the following comment in my patch?

Yes, I did both read your patch and that comment.

> are you talking about something different?
>=20
> +	/*
> +	 * XXX
> +	 * this chunk of the code is common between some filesystems
> +	 * which rely on side effects of lookup.
> +	 * probably it's better to make this into a subroutine.
> +	 */

My thought process is that: 1) we _should_ have these common routines. 2)=
=20
When we create said routine(s), I think the local file system one look=20
almost exactly like the cache_lookup() routine and friends we have now. 3)=
=20
I think we will be able to come up with routines for remote file systems=20
that will be not far from our cache_lookup() routines now(*).

(*) We could of course come up with routines very different, but I don't=20
think we have to.

My thought is that if we make your changes and then latter add common=20
routines, we won't be that far from where we are now. It will be like we=20
take eight steps north then seven steps south. So why not just make the=20
one step now and save a lot of grief?

I mean what really is wrong with what we have now? The fact that=20
cache_lookup() will remove entries if MAKEENTRY is not set is wrong. We=20
want to remove it for remote file systems, and if we do we want to tweak=20
local file systems as you did in your initial patch. Since we will now get=
=20
into the negative-cache-entry case for DELETE and RENAME operations, we=20
need to define what we want to have happen there. We also need the changes=
=20
you proposed to nfs and smbfs.

Other than that, what do we need to do? What semantics do we need to add=20
or change?

Put another way, I think we can change our current name cache routines to=
=20
support remote file system semantics in addition to supporting local file=
=20
system semantics. I think these changes will be smaller than the changes=20
you just proposed.

I also think that your initial patch changed so that instead of changing=20
lookup to not "docache" we instead change cache_lookup() to not remove=20
entries will give us the two caching behaviors you've descirbed.

Does that make more sense?

Take care,

Bill

--E/DnYTRukya0zdZ1
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAcOKNWz+3JHUci9cRAl+DAJ0cGWQRAkelmnGfpngsC1Ltz/f96wCeO1MV
SAAWhd1wzDJzxDLcsdi9WsU=
=8sKY
-----END PGP SIGNATURE-----

--E/DnYTRukya0zdZ1--