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

On Mon, Oct 13, 2003 at 06:47:47PM +0200, Manuel Bouyer wrote:
> On Mon, Oct 13, 2003 at 09:37:15AM -0700, Bill Studenmund wrote:
> > > I'm not sure I follow you here. For devices with several deepth of
> > > subdevices (e.g atabus -> atapibus -> sd), we can't probe sd before
> > > atapibus is attached (because we need the atapibus's kernel thread for
> > > example).
> >=20
> > We do whatever is needed to make the probe happen. The tree-like struct=
ure=20
> > was more a reference to USB.
> >=20
> > Do we really have an atabibus thread _and_ an atabus thread covering the
> > same sd? That seems rather wasteful.
>=20
> The atabus thread covers everything attached to the atabus (that is,
> wd and low level requests from atapibus).
> The atapibus thread covers what's attached to the atapibus, for high-level
> functionalities.

As long as the atapibus operations happen within a thread context, does it=
=20
matter if it's the "atapi" or "ata" thread?

> I've been thinking of ways to have a single thread handle boths. The prob=
lem
> is that we can have atapibus without atabus, or atabus without atapibus (=
and
> atapibus can attach to something else than atabus).

I think the solution to that is that you require whatever ataches an atapi=
=20
bus do so within a thread context. Take the atapi bus thread creation code=
=20
out of atapi code, and put it in the atachers that don't already have a=20
thread per device.

You already must have some sort of API that the ata bus exports to the=20
atapibus, so just extend it to include the (implicit) presence of a=20
thread.

Take care,

Bill

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

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

iD8DBQE/itoQWz+3JHUci9cRApF8AKCMBPl1zZiI/Lui1Tk9hbNQ3xqnyQCfZzqP
q7BzwlGtc9OtG0JjfkmSYg0=
=H0pf
-----END PGP SIGNATURE-----

--KlAEzMkarCnErv5Q--