The .device field is set during the bus scan, essentially during
sd_attach. After this is done, sd_finish is called for post-processing,
which is where you end up calling scsi_init_onedisk et. al. I cannot tell
quite what code you are referring to, but my guess is that you are looking
at a chunk of sd_finish() where we loop over the devices. The idea is that
an element of rscsi_disks[] with a NULL .device field is essentially an
unused slot that could be used if a new device were to appear as a result of
a new module being loaded. If you were to unload a low-level driver, the
sd_detach() function would zero the .device field when it disconnects so
that the slot becomes unused.
The code in question is simply looping over all of the known devices.
Does this answer your question?
-Eric
----- Original Message -----
From: "Alexander Viro" <[EMAIL PROTECTED]>
To: "Alan Cox" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, January 14, 2000 4:02 AM
Subject: [Question] rscsi_disks[].device being NULL
> ... how can it happen in revalidate_scsidisk()? Immediately before
> checking for it we do scsi_init_onedisk(target); and this one would die
> horrible death if rscsi_disk[target].device was NULL. So either it's too
> late or it is always false. Unless you object I'll remove it - it stands
> on the way of resetup_one_dev() patch...
> Al
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
