On Sun, 16 Jan 2000, Eric Youngdale wrote:
>
> ----- 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.
Eric, could you tell me what reads partition tables if we attach new disk
when system is already booted? sd_finish() via revalidate_scsidisk()?
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
