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

On Sat, Oct 11, 2003 at 01:21:58PM +0200, Manuel Bouyer wrote:
> On Fri, Oct 10, 2003 at 11:40:56AM -0700, Bill Studenmund wrote:
> > When it's time to do "defered probe", we tell ALL the defered probe=20
> > devices to start probing. The threads then kick off probing. They will=
=20
> > probe as agressively as they can (i.e. in parallel).
>=20
> It's not always appropriate to do things as fast as we can, in parallel.
> I have several boxes with SCSI disks where auto spin up of the disks are
> disabled, and I rely on the sequential prove to have them spin up sequent=
ially.
> If they all spin up at the same time there could be power problems.
>=20
> Note that I don't think your proposal would cause problems here (the
> spin up happens at attach time, and attach are still sequencial here,
> if I understood it properly), just a general point.

The heavy-iron I've seen that has to worry about power addressed it=20
directly. I know the Convex disk racks we had at NASA had three power=20
strips, and had delayed power-up on them. That way everything started up=20
fine, and no OS intervention needed.

> > We then go to the first device in the "defered probe" list and ask it t=
o=20
> > tell us about its first subdevice. Note, we do this in the "main kernel=
"=20
> > thread, not one of the spawned probe threads.
> >=20
> > Each "defered probe" device has some internal probe order. For SCSI SPI=
=20
> > (parallel SCSI), this would be target ID. For ata I think it's=20
> > master/slave. For USB I think it's port on chip, then ports on hubs und=
er=20
> > that, etc. The point is there's a reproducable scan order, so if the=20
> > hardware doesn't change we'll find it in exactly the same order.
> >=20
> > So when we ask a "defered probe" device for it's next subdevice, it will
> > find one of four things: (a) there are no more subdevices, (b) we found
> > something at the next subdevice, (c) we found nothing at the next
> > subdevice, or (d) we don't know yet as the probes are still occuring.
> >=20
> > If we find (a) or (b), we return that info. If we find (c), the device=
=20
> > internally scoots its pointer forward and looks at the next subdevice=
=20
> > location. If we find (d), we sleep until the probe thread finds somethi=
ng=20
> > for that slot, and reevaluate.
> >=20
> > My expectation is that "returning (b)" will cause that device to be=20
> > attached, and have info printed out.
> >=20
> > One big advantage of this idea is that we have one solution that will
> > enable any sort of defered-probe device family to be attached in a
> > repeatable order, yet we probe the devices in parallel as much as we ca=
n.
> >=20
> > This idea does mean we will have a transient allocation of locators, wh=
ich
> > are fed from the probe thread to the attach thread. For SPI, a packed
> > array of 2-bit ints may suffice (unprobed, nothing, just-LUN-0,
> > many-LUNs), but other busses may need something more tree-like. Once th=
ese=20
> > locators get to the attach thread, they are turned into devices.
>=20
> 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).

We do whatever is needed to make the probe happen. The tree-like structure=
=20
was more a reference to USB.

Do we really have an atabibus thread _and_ an atabus thread covering the
same sd? That seems rather wasteful.

Take care,

Bill

--kXdP64Ggrk/fb43R
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/itS7Wz+3JHUci9cRAtZOAJsFjaS12UFk9Xcf39/xNSOXvzEffACfav8F
uN/xBd3XoYiu42N+NCWWXNg=
=Jqfl
-----END PGP SIGNATURE-----

--kXdP64Ggrk/fb43R--