----- Original Message -----
From: "Guest section DW" <[EMAIL PROTECTED]>
To: "Alexander Viro" <[EMAIL PROTECTED]>; "Alan Cox"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, January 15, 2000 10:33 PM
Subject: Re: [Question] rscsi_disks[].device being NULL
> On Fri, Jan 14, 2000 at 04:02:32AM -0500, Alexander Viro wrote:
>
> > ... 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.
>
> Right.
> (And if I am not mistaken rscsi_disks[].device is only set
> to zero in sd_detach(), called by the proc code and by
> scsi_unregister_host() and scsi_unregister_device() in scsi.c.)
Not strictly true. We overallocate rscsi_disks[] with SD_EXTRA_DEV
extra slots. This leaves room for expansion as modules are loaded, as we
currently don't have the locking in place to grow the thing dynamically.
The unused slots are initialized with a NULL value in .device.
Again, fixing this to allow rscsi_disks to grow on the fly is on my list
of things to do, and the main trick is to get the correct locking added so
that we don't introduce race conditions. This was something that I wasn't
going to do until early in the 2.5 series.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
