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

On Thu, Sep 08, 2005 at 11:08:41AM +0900, YAMAMOTO Takashi wrote:
> > However, it's the necessary thing within the present
> > interface, and helps teach jrp about that interface and its
> > deficiencies for this goal :)
>=20
> not strictly necessary.  you can move requests from the temporary bufq
> to new bufq again.  (i'm not saying that it's a good idea. :-)

Heh, I suppose you could, at that :)

It would protect against the case where some implementation keeps a
pointer back to its parent bufq_state struct, which was something else
I was worried might happen.

It also strikes me that a bufq_realloc() (or calling bufq_alloc() on
an existing queue, perhaps with a REALLOC flag?) could do all of this
work in place on the struct in the softc, and require that it be
called by the driver inside the appropriate spl or locking for that
driver.  It could avoid the double move because it lives inside the
interface abstraction and can use the function pointers directly.

> > We already have some bufq types that contain
> > other bufq's, like the multi-level READPRIO.
>=20
> what's "multi-level READPRIO" ?

Sorry, I was too short with that description.  The queue behind
NEW_BUFQ_STRATEGY (aka READPRIO) contains two other queues internally,
one for reads and the other writes. That's what I meant by a
multi-level queue. A similar idea might be used to implement a queue
that includes switching between internal queues (puts into new, gets
from old until empty).

But I like the realloc idea better.

--
Dan.
--hk6Zb6cduJ+I0Tmj
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDH6PNEAVxvV4N66cRAnb7AKDKf+FI9gAUYAjaf49tfuV0JEuV+QCcDKm1
0VUMPAN+RW5gaMAetPt0PD0=
=XlhH
-----END PGP SIGNATURE-----

--hk6Zb6cduJ+I0Tmj--