Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE)

[Phillip Susi <psusi@cfl.rr.com>]

david@lang.hm wrote:
> is it really enough to do the sync followed by the async piece?
>
> it seems to me that there may be a need for three steps
>
> 1. prep (sync, what we do today)
> which will all complete before
> 2. parallel (async)
> which will all complete before
> 3. cleanup (sync)

I agree.  Considering the particular case of scsi disks, you want to do 
the long INQUIRY command to probe each target in phase 2, so that this 
time consuming step can be done in parallel between multiple scsi 
busses.  After the INQUIRY though, you have to register with the scsi 
layer and assign it a minor number and so on, and this you want to do 
with some predictability, so you need to do this in phase 3.

Take a hypothetical system containing a PCI bus with a video card and 
two scsi cards in it, and each scsi bus has a hard disk on it.  The 
sequence would go:

1) PCI Bus invokes phase 1 on video card, scsi a, scsi b, in that order
2) PCI Bus invokes phase 2 on video card, scsi a, scsi b, each in their 
own thread
2.1) video card uploads firmware
2.2) scsi bus A issues INQUERY commands to each target to detect devices
2.3) scsi bus B issues INQUERY commands to each target to detect devices
3) PCI Bus invokes phase 3 on video card, scsi a, scsi b, in that order
3.1) video card registers with the frame buffer layer
3.2) scsi bus A registers its detected disk with the scsi layer
3.3) scsi bus B registers its detected disk with the scsi layer


Because 3.2 and 3.3 always happen in order, /dev/sda will stay /dev/sda 
even if 2.3 finishes before 2.2.  Likewise if you add a new video card 
to PCI slot 4 which does not require a firmware upload, it will not 
displace the existing video card from /dev/fb0 because phase 3 will take 
place for the first card first, even if phase 2 completed first on the 
new card.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/