--cW+P/jduATWpL925
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 08, 2005 at 10:22:50AM +0900, YAMAMOTO Takashi wrote:
> > YAMAMOTO please review it again (reload the URL).
>=20
> - no one seems to allocate tbufq.

Yeah, I'm re-clarifying that - the idea was to use stack space for
this struct, but it still wound up as only a pointer.

> - don't assume that splbio() is a right way to protect bufq.
>   how to protect bufq is up to each drivers.

Hm...  that was my assumption, but it's a very good point.

> - copying bufq_state is evil.
>   (although i know that there is a driver which does it..)
>   it's the reason why i suggested to refine bufq interface.

Yes, it is, and I've indicated my concerns about it too.  I also worry
about drivers that might have copied/cached pointers to the bufq
elsewhere. However, it's the necessary thing within the present
interface, and helps teach jrp about that interface and its
deficiencies for this goal :)

I also made another suggestion, which I don't like much either, within
the existing interface.  We already have some bufq types that contain
other bufq's, like the multi-level READPRIO.  If the disk driver softc
pointed to a BUFQ_SWITCHABLE type, that could contain the real
schedulers internally, and deal internally with letting one drain
before freeing it, or doing the move.  It means potentially forwarding
all requests through another indirection in the normal case, unless it
was clever about changing its own get/put function pointers.

> - don't assume BUFQ_SORT_RAWBLOCK.
>=20
> - why disk_ prefix rather than bufq_ ?

No comment on these.

--
Dan.
--cW+P/jduATWpL925
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDH5VqEAVxvV4N66cRAgYKAJ9JxI5GhcoYwTAfqdz2BeDHV3jirQCgs8JI
M2UOrK82aSgZQh3Lglw4QOU=
=KPa1
-----END PGP SIGNATURE-----

--cW+P/jduATWpL925--