Subject: Re: Redoing file system suspension API (update)
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 06/21/2006 13:50:06
--aM3YZ0Iwxop3KEKx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 18, 2006 at 10:59:33PM +0900, YAMAMOTO Takashi wrote:
> thanks for taking a look of this.
> although i have many negative comments, i think it's a step forward. :-)

I forgot to mention this in my other note, but I too want to thank you for=
=20
proposing this. We will have much more concrete and hopefully constructuve=
=20
discussions this way. :-)

> first of all, i tend to think filesystem snapshot thing should be done
> entirely in filesystem-dependent code.

Yamamoto-san, I think that it's reasonable for upper layers to have to
help with some things, such as when the upper layer wants to perform an
extended sequence of operations as if they were atomic. But I agree with
you that when VOP_ or VFS_ atomicity is fine, that the file system should
handle this; we don't have to add locking to EVERYTHING.

> > - Instead of tracking possible long sleeps I put the suspend/resume into
> >   ltsleep().
>=20
> why?
>=20
> i don't think it's desirable for each subsystems to put their own
> random hooks in these places.
>=20
> what happens if a filesystem itself sleeps with PCATCH?
> (maybe you can call it a bug, but we currently have such a code.)

To be honest, I don't think PCATCH is a bug. Yes, the file system has to=20
be careful about atomicity requirements, but if it is careful, it's fine.=
=20
:-)

> > ** The new API is:
> >=20
> > Using explicit enter()/leave() pairs adds much complexity so I took ano=
ther
> > approach. I use two types of gates.  Normal gates need a "leave" operat=
ion.
> > Permanent gates are valid until the thread returns to user mode.
>=20
> while it can make your patch smaller, i think it's actually more complex
> and harder to understand and maintain.

I think understanding and maintenance are very important. That's one of my=
=20
current concerns with this change. :-)

Take care,

Bill

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

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

iD8DBQFEmbD+Wz+3JHUci9cRAga6AJ9IMeFuUTqvQwlrPFtI43ks7X8vcACgjE3I
I+HC1UT7TECCZXpd4guJ6Kg=
=ldsa
-----END PGP SIGNATURE-----

--aM3YZ0Iwxop3KEKx--