Subject: Re: interleaved disk probing output
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 10/10/2003 11:40:56
--KdquIMZPjGJQvRdI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 10, 2003 at 07:27:09PM +0200, Manuel Bouyer wrote:
> On Fri, Oct 10, 2003 at 10:16:06AM -0700, Matt Thomas wrote:
> > Wouldn't it make more sense to change the aprint stuff to deal with thi=
s?
> > Add a parameter that will store the buffered output until a newline is
> > reached and then emits it as one large chunk?
> >=20
> > aprint_create(&ctx);
> > aprint_buffered(ctx, ...);
> > aprint_destroy(ctx);
>=20
> Then you could have wd0 and sd0 interleaved.
> It would be OK, I guess, if we could put several lines in the buffer.
> We still needs an ordering between atapi and SCSI though, so that
> ordering of devices between atapi and scsi don't change between reboots.

One idea I've had for a while is why not use config to order things. I'm=20
not articulating this well, so please bear with me. This idea seems a lot=
=20
like what Alex was proposing, but I think more concrete.

Right now (as I understand it) we have a thread for each scsibus and that=
=20
thread prints stuff out. We also have threads for atapi and usb. They too=
=20
print stuff out.

My thought is why not do all the printing in one main thread, and have all=
=20
the other threads instead feeding info to said thread. We're=20
multithreaded, let's use it to our advantage.

So here's how it'd work. As we are probing, we find scsibusses (and ata=20
busses I guess and usb). We add each scsibus to a "defered probe" list,=20
which is ordered.

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).

We then go to the first device in the "defered probe" list and ask it to=20
tell us about its first subdevice. Note, we do this in the "main kernel"=20
thread, not one of the spawned probe threads.

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 under=
=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.

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.

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 something=
=20
for that slot, and reevaluate.

My expectation is that "returning (b)" will cause that device to be=20
attached, and have info printed out.

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 can.

This idea does mean we will have a transient allocation of locators, which
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 these=
=20
locators get to the attach thread, they are turned into devices.

Thoughts?

Take care,

Bill

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

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

iD8DBQE/hv04Wz+3JHUci9cRAsUDAJ4kw0jjQndegzc039bV5u5CVG1XBwCcCpY4
PKR9MKeuwdYYijmf5rQjjVc=
=Qjm9
-----END PGP SIGNATURE-----

--KdquIMZPjGJQvRdI--