Re: SCSI scanning

From: Linus Torvalds (torvalds@transmeta.com)
Date: Sun Sep 17 2000 - 19:43:20 EST


On Sun, 17 Sep 2000, Jan Niehusmann wrote:
>
> 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?

No.

The above seems to be the bug. Or at least part of it.

CONFIG_BLK_DEV_SD is only defined for the non-modular case.

The config options behave differently on a C and on a configuration level.
On a Makefile/config level, they have values like "y"/"m"/"n". On a C
level, the logic is

        "y" -> #define CONFIG_XXX 1
        "m"/"n" -> #undef CONFIG_XXX

which may not be logical, but that's how it has historically always
worked.

(Actually, it ends up being fairly logical - think of the Makefile level
as the level that decides what and when things get compiled, and the C
level is used to determine what _other_ things the code can depend on
being enabled - something being a module is irrelevant).

So the above code behaves differently depending on whether BLK_DEV_SD is a
module or not.

This is somethin gI've been trying very hard to go away - behaviour should
_not_ depend on whether something is a module, and it should not be
visible on a source code level. I want well-behaving modules to act as if
being compiled into the kernel was just a matter of being "early-loaded".
That way there is only one path through the system, and we don't get the
kind of problems that used to plague different drivers where they acted
quite differently depending on whether they were modular or not.

(Why do I hate that? I don't use modules myself, and I hate getting
bug-reports on something that is broken when modular. So I want the
modular case to be the same as the non-modular case, so that I don't need
to worry about testing two entirely different configurations).

> > 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.

I don't agree. I suspect that the change to remove the one or two places
like the above are not only as small, but they will mean that the problem
is fixed once and for all.

                Linus

-
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