On Sun, Sep 17, 2000 at 09:59:30AM -0700, Linus Torvalds wrote:
> On Sun, 17 Sep 2000, Torben Mathiasen wrote:
> >
> > The proper way of fixing this is to add #ifdef MODULE around the init
> > functions or going back to init/exit_module.
>
> Please explain why it does it twice for compiled-in, and only once for
> modules. There must be some other logic that does the extra
> initializations (and that does not trigger for modules), and I'd much
> rather just get rid of THAT thing instead.
The call to sd_init is in lines 1577ff of scsi.c :
for (sdtpnt = scsi_devicelist; sdtpnt; sdtpnt = sdtpnt->next)
if (sdtpnt->init && sdtpnt->dev_noticed)
(*sdtpnt->init) ();
Just commenting this out is curing the biggest problem (at least for me),
as now the scsi discs show up only once in /proc/partitions. But there is
still a duplicated "Detected scsi disk" message, so not everything is fine.
Further investigation shows that this duplication is caused by the call
to scan_scsis in line 1565 of scsi.c, and this one can not be commented out
as it is needed.
But I have some problems understanding all the module/non-module stuff:
hosts.c, lines 1002-1004, look as follows:
#ifdef CONFIG_BLK_DEV_SD
scsi_register_device(&sd_template);
#endif
If I understand that correctly, the line is executed for both
CONFIG_BLK_DEV_SD=m and CONFIG_BLK_DEV_SD=y, isn't it? But if sd is compiled
as a module, sd_template should not be available, as it's defined inside sd.c.
> Basically, there has to be some other place that does the equivalent of
>
> if (!module) init_subsystems();
As I said above, this if(!module) is probably the #ifndef MODULE section in
scsi.c.
> and I don't see why we can't just remove that one and make modules and
> compiled-in behave the same.
We probably should, but this would mean changes to scsi.c, hosts.c,
and perhaps scsi_module.c, which is included in every low level scsi driver.
This may not be a change we want to do in 2.3, the additional #ifdef MODULE
in sd.c and sr.c is a much smaller change.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:15 EST