On Fri, Oct 10, 2003 at 11:40:56AM -0700, Bill Studenmund wrote:
> One idea I've had for a while is why not use config to order things. I'm 
> not articulating this well, so please bear with me. This idea seems a lot 
> 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 
> thread prints stuff out. We also have threads for atapi and usb. They too 
> print stuff out.
> 
> My thought is why not do all the printing in one main thread, and have all 
> the other threads instead feeding info to said thread. We're 
> multithreaded, let's use it to our advantage.
> 
> So here's how it'd work. As we are probing, we find scsibusses (and ata 
> busses I guess and usb). We add each scsibus to a "defered probe" list, 
> which is ordered.
> 
> When it's time to do "defered probe", we tell ALL the defered probe 
> devices to start probing. The threads then kick off probing. They will 
> probe as agressively as they can (i.e. in parallel).

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 sequentially.
If they all spin up at the same time there could be power problems.

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.

> 
> We then go to the first device in the "defered probe" list and ask it to 
> tell us about its first subdevice. Note, we do this in the "main kernel" 
> thread, not one of the spawned probe threads.
> 
> Each "defered probe" device has some internal probe order. For SCSI SPI 
> (parallel SCSI), this would be target ID. For ata I think it's 
> master/slave. For USB I think it's port on chip, then ports on hubs under 
> that, etc. The point is there's a reproducable scan order, so if the 
> 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 
> internally scoots its pointer forward and looks at the next subdevice 
> location. If we find (d), we sleep until the probe thread finds something 
> for that slot, and reevaluate.
> 
> My expectation is that "returning (b)" will cause that device to be 
> 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 
> locators get to the attach thread, they are turned into devices.

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

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--