Re: [PATCH] Re: SCSI scanning

[Michael Elizabeth Chastain]

Hi Helge,

helge> Ability to put one particular controller first solves the boot issues
helge> just fine though.

Ah, here is a boot option for you:

append="scsihosts=imm:advansys:advansys:aha1542"

Read this:

http://www.torque.net/scsi/scsihosts.html

Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Peter Samuelson]

[I wrote]
> Unfortunately, your drivers/scsi/foo.o actually represents the
> zillions of host drivers we have, so the DRIVERS assignment starts to
> look rather daunting and hackish.

I retract that -- I had forgotten that lowlevel is all pulled into
hosts.o.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Peter Samuelson]

[mec]
> Can you characterize the problem in more detail for me?  That is,
> exactly what link order constraints you are trying to obey.

As has been explained, scsi lowlevel (drivers) need to come before scsi
toplevel (sd, sr, st, sg) because sd and sr cannot dynamically resize
arrays of drives -- so they really want know how many you have, up
front.  (You can pick a max number in Config.in but that's a kludge.)
And scsi midlevel (core) has to come first because lowlevel uses it.

Of course there are internal ordering needs in lowlevel too but those
are much easier to handle.

> # Makefile
> link-first := drivers/scsi/foo.o drivers/i2o/%o drivers/scsi/bar.o
> link-last :=
> 
> DRIVERS := \
>   $(filter $(link-first), $(DRIVERS)) \
>   $(filter-out $(link-first) $(link-last), $(DRIVERS)) \
>   $(filter $(link-last), $(DRIVERS))

Not bad.  Unfortunately, your drivers/scsi/foo.o actually represents
the zillions of host drivers we have, so the DRIVERS assignment starts
to look rather daunting and hackish.  Not to mention impossible to
maintain -- it shouldn't be necessary to edit the toplevel Makefile to
add a scsi host driver.

IMHO the real solution is to split scsi, like net/ vs. drivers/net/.
SCSI lowlevel -> drivers/scsi/, midlevel -> scsi/, sd and sr -> block/,
st and sg -> char/.  (Or sd/sr/st/sg all into scsi/, possibly.)

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Michael Elizabeth Chastain]

Eric Youngdale writes:

> .initcall.init : { *(.initcall.init1) }
> .initcall.init : { *(.initcall.init2) }
> .initcall.init : { *(.initcall.init) }

I like this idea.

I would add initcall.init8 and initcall.init9 in order to have some
levels after the normal initcalls.

> It isn't as ugly as jumping through millions of hoops to get the Makefiles
> to do it right.

It's about three lines in Rules.make to do link ordering in each
directory.

But the situation in scsi right now requires cross-directory ordering
and that is going to be some ugly hoop-jumping if done in Makefiles.

Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Thu, Sep 21 2000, Michael Elizabeth Chastain wrote:
> torben> core-hosts/i2o-upper.
> 
> Ok, I understand the problem.
> 
> Can you elaborate some more on exactly which files go in "core",
> "hosts", and "upper"?  My understanding is:
> 
> # drivers/scsi
> scsi-core-files  := scsi_mod.o scsi_syms.o
> scsi-hosts-files := ... everything not in core and upper ...
> scsi-upper-files := st.o sd_mod.o sr_mod.o sg.o
> 
> # i2o
> i2o-files:= %.o
>

Eaxctly. The core and upperlayers are ok now. You just need 
to get all hosts adapters into hosts.o. Everything is there
except those outside drivers/scsi. It would be great if
someone with an i2o adapter could verify any changes.
Please note I already sorted the hosts.o files in the drivers/scsi/Makefile. 

> I can do this in the top Makefile by declaring lists like the above
> using $(filter) and $(filter-out).  The hard part is going to be defining
> "scsi-hosts-files" to work properly.  I think I will need to add a few
> more lines to drivers/scsi/Makefile and make one more multi.  Or maybe
> three more multis.

Yeah I've been thinking of doing this, but was afraid to srew it up. Give
it a try, and lets see what Linus thinks. 

BTW, while you are at it, could you rename sg.o to sg_mod.o. It would
look better...

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Michael Elizabeth Chastain]

torben> core-hosts/i2o-upper.

Ok, I understand the problem.

Can you elaborate some more on exactly which files go in "core",
"hosts", and "upper"?  My understanding is:

# drivers/scsi
scsi-core-files  := scsi_mod.o scsi_syms.o
scsi-hosts-files := ... everything not in core and upper ...
scsi-upper-files := st.o sd_mod.o sr_mod.o sg.o

# i2o
i2o-files:= %.o

I can do this in the top Makefile by declaring lists like the above
using $(filter) and $(filter-out).  The hard part is going to be defining
"scsi-hosts-files" to work properly.  I think I will need to add a few
more lines to drivers/scsi/Makefile and make one more multi.  Or maybe
three more multis.

But I'm sure I can do it without moving any source files around.

torben> The perfect solution would be to remove the link order
torben> dependency. 

Yeah, I agree with Linus: minimizing link order dependencies is the
right thing.

For the link order dependencies which *do* exist at any point in time,
I'd like the Makefiles to have explicit link-ordering declarations with
comments on them about why they are needed.

Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Thu, Sep 21 2000, Michael Elizabeth Chastain wrote:
> Torben Mathiasen wrote:
> 
> > I can't seem to find a clean way of getting the drivers outside
> > "drivers/scsi" to link _after_ the other low-level drivers.
> 
> Can you characterize the problem in more detail for me?  That is,
> exactly what link order constraints you are trying to obey.
> 
> I am thinking about this:
> 
> # Makefile
> link-first := drivers/scsi/foo.o drivers/i2o/%o drivers/scsi/bar.o
> link-last :=
> 
> DRIVERS := \
>   $(filter $(link-first), $(DRIVERS)) \
>   $(filter-out $(link-first) $(link-last), $(DRIVERS)) \
>   $(filter $(link-last), $(DRIVERS))
>

Okay, in pre5 I got the scsi system to link

core-hosts-upperlayers.

We need to get the drivers outside drivers/scsi to link
as the _last_ ones in the host section:

core-hosts/i2o-upper.

Now this is difficult without moving things around, which is
bad. I'm not a makefile guru, so if you have any ideas go
for it. Alan problaly wants to verify the i2o stuff...

The perfect solution would be to remove the link order
dependency. 

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Michael Elizabeth Chastain]

Torben Mathiasen wrote:

> I can't seem to find a clean way of getting the drivers outside
> "drivers/scsi" to link _after_ the other low-level drivers.

Can you characterize the problem in more detail for me?  That is,
exactly what link order constraints you are trying to obey.

I am thinking about this:

# Makefile
link-first := drivers/scsi/foo.o drivers/i2o/%o drivers/scsi/bar.o
link-last :=

DRIVERS := \
$(filter $(link-first), $(DRIVERS)) \
$(filter-out $(link-first) $(link-last), $(DRIVERS)) \
$(filter $(link-last), $(DRIVERS))

This is just a preliminary thought.  I'd like to know more about the
problem.

Michael Elizabeth Chastain

"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Linus Torvalds]

On Wed, 20 Sep 2000, Eric Youngdale wrote:
> 
> Some of problems that are forcing ordering requirements are better fixed
> in 2.5.  The cleanups to allow disk and cdrom drivers to dynamicly resize
> are probably in this category.  If you disagree, I can take a stab at it,
> but some of the changes won't be simple.

Oh, I don't disagree at all.

I think we'll have the old order (Torben's patches seem to do that as far
as I can tell) for now, but I just wanted the long-range plan to be that
we shouldn't be as order-fragile as we are. 

No point in doing that now.

> My thinking is that for 2.4 we can impose a simple ordering by adding a
> few lines to vmlinux.lds (the linker script that is used to collect assorted
> ELF sections together, which lives in arch//vmlinux.lds).  Thus
> instead of:

[deleted]

Yeah, I've considered it. For other reasons. We already have a few stages
of ordering, like having to initialize things like PCI etc before
initializing PCI devices, and right now those stages are all explicit (ie
pci_init() is _not_ an initcall).

Maybe.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Eric Youngdale]

- Original Message -
From: "Linus Torvalds" <[EMAIL PROTECTED]>
To: "Torben Mathiasen" <[EMAIL PROTECTED]>
Cc: "Eric Youngdale" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, September 19, 2000 6:59 PM
Subject: Re: [PATCH] Re: SCSI scanning


>
>
> On Wed, 20 Sep 2000, Torben Mathiasen wrote:
> >
> > I can't seem to find a clean way of getting the drivers outside
"drivers/scsi"
> > to link _after_ the other low-level drivers. My linux Makefile abilities
is
> > limited though, so if someone with the knowledge would do what Eric
requests
> > above please. We will probaly have to move some thing around, and that
would be a
> > _bad_ move at this point I guess.
>
> Note that ordering requirements are usually bad requirements. In many
> cases it's probably best to just fix the problem that causes ordering
> requirements in the first place.

Some of problems that are forcing ordering requirements are better fixed
in 2.5.  The cleanups to allow disk and cdrom drivers to dynamicly resize
are probably in this category.  If you disagree, I can take a stab at it,
but some of the changes won't be simple.

It isn't that I don't want to do it - I have been itching to clean this
up for some time now anyways - and it was getting near the top of things to
do :-).  Actually once the groundwork is laid, the work for drivers outside
of SCSI could be handled by others, or even deferred (which in itself would
simplify the task) to 2.5.

We did get the character device (tape and generic) cleaned up so
*technically* there are no ordering requirements for those two.  It is only
disk and tape that still have this problem, and it is the only issue that
imposes any ordering at all (other than the question of newer drivers/older
drivers, which can easily be addressed in the Makefile).

> So we don't need to do a "perfect" job on ordering. In fact, we probably
> want to avoid ordering as much as possible - I'd rather fix the problems
> that cause us to want to order thing than spending much time trying to
> order stuff.
>
> Some ordering is simple: making sure that newer drivers show up before
> older drivers that can catch on compatibility stuff. Some other cases are
> equally obvious: keeping the sort in pretty much the same order as the old
> hosts.c file just to avoid having peoples disks being re-ordered if
> somebody has multiple types of SCSI controllers. That's more of a "let's
> be polite" thing.
>
> But let's fix the real problems rather than hit our heads against the
> ordering wall..

My thinking is that for 2.4 we can impose a simple ordering by adding a
few lines to vmlinux.lds (the linker script that is used to collect assorted
ELF sections together, which lives in arch//vmlinux.lds).  Thus
instead of:

 .initcall.init : { *(.initcall.init) }

we could instead have:

 .initcall.init : { *(.initcall.init1) }
 .initcall.init : { *(.initcall.init2) }
 .initcall.init : { *(.initcall.init) }

It would be trivial to ensure correct order by making the scsi core 1, make
the host adapters 2, make the upper level adapters normal initcall.
Everything else is left alone.  If there is anything that needs to be
initialized prior to SCSI, we could invent an initcall.init0, but I doubt
that there is anything that would fit into this category.

It isn't as ugly as jumping through millions of hoops to get the Makefiles
to do it right.

-Eric


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanning changes break RAID autorun

[Peter Samuelson]

[Matthew Kirkwood]
> +ifeq ($(CONFIG_BLK_DEV_MD),y)
> +SUB_DIRS += md
> +MOD_SUB_DIRS += md
> +else
> +  ifeq ($(CONFIG_BLK_DEV_MD),m)
> +  MOD_SUB_DIRS += md
>endif
>  endif
>  

Drop the 'else' bit; CONFIG_BLK_DEV_MD cannot be 'm'.

> +obj-n:=
> +obj- :=

These two variables are unused, don't bother initializing them.
We only care about obj-y and obj-m.

Rest looks OK (eyeballed, not tested).

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Keith Owens]

On Wed, 20 Sep 2000 11:42:24 +0200, 
Helge Hafting <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>> To handle newer controllers which mimic older controllers, the newer
>> controllers would be listed in LINK_FIRST.  At the moment we do not
>> have any plans to allow user ordering of controllers via .config, only
>> via editting the Makefile.  The plan is to clean up the Makefiles
>> first, introducing new facilities comes later (if ever).
>
>Interesting.  Do you mean that you don't want any user reordering via
>.config at all, or merely that you yourself have more
>important stuff to do.  I can code up something myself if I 
>feel the need.  Complete control of order is ideal, it solves
>every problem an expert user might have.  Ability to
>put one particular controller first solves the boot issues
>just fine though.

Current plans are to replace the current Makefile kludges with clean
code that does the same thing, gets it right where current Makefiles
are broken, is easier to maintain and (hopefully) is faster.  The
kbuild mantra is "Correctness, Maintainability, Speed", in that order.

Part of the correctness and maintainability problem is the lack of
documentation on required link orders in the existing Makefiles.
People are scared to change the order of object entries because that
defines link order and we do not know if existing orders are required
or they are just coincidence.

Once the orders are fully defined as LINK_FIRST, LINK_LAST and the
rest, then we can think about allowing make xxx_config to change the
orders.  However that would be after the Makefile rewrite had been
accepted.  It would probably require the use of CML, I don't think the
current make xxx_config language can cope with this sort of input.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Helge Hafting]

Keith Owens wrote:
> 
> On Wed, 20 Sep 2000 10:43:35 +0200,
> Helge Hafting <[EMAIL PROTECTED]> wrote:
> >Ideally I'd like specifying controller order in menuconfig.  Perhaps a
> >"controller order" submenu in scsi, that display the default order
> >of the selected controllers.  The user can then change this.
> >I guess that is 2.5 stuff though.
> 
> Part of the 2.5 Makefile redesign is adding LINK_FIRST and LINK_LAST
> entries in Makefiles.  The link order will be $(LINK_FIRST), (the
> rest), $(LINK_LAST).  Link first and last entries will be done in the
> Makefile defined order, the rest will be linked in alphabetical order.
> 
> And there will be a great big note: Do not use LINK_FIRST or LINK_LAST
> unless you really (and I mean *REALLY*) have to!  All reasons for using
> LINK_FIRST and LINK_LAST must be documented.
> 
> To handle newer controllers which mimic older controllers, the newer
> controllers would be listed in LINK_FIRST.  At the moment we do not
> have any plans to allow user ordering of controllers via .config, only
> via editting the Makefile.  The plan is to clean up the Makefiles
> first, introducing new facilities comes later (if ever).

Interesting.  Do you mean that you don't want any user reordering via
.config at all, or merely that you yourself have more
important stuff to do.  I can code up something myself if I 
feel the need.  Complete control of order is ideal, it solves
every problem an expert user might have.  Ability to
put one particular controller first solves the boot issues
just fine though.

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Keith Owens]

On Wed, 20 Sep 2000 10:43:35 +0200, 
Helge Hafting <[EMAIL PROTECTED]> wrote:
>Ideally I'd like specifying controller order in menuconfig.  Perhaps a
>"controller order" submenu in scsi, that display the default order
>of the selected controllers.  The user can then change this.
>I guess that is 2.5 stuff though.

Part of the 2.5 Makefile redesign is adding LINK_FIRST and LINK_LAST
entries in Makefiles.  The link order will be $(LINK_FIRST), (the
rest), $(LINK_LAST).  Link first and last entries will be done in the
Makefile defined order, the rest will be linked in alphabetical order.

And there will be a great big note: Do not use LINK_FIRST or LINK_LAST
unless you really (and I mean *REALLY*) have to!  All reasons for using
LINK_FIRST and LINK_LAST must be documented.

To handle newer controllers which mimic older controllers, the newer
controllers would be listed in LINK_FIRST.  At the moment we do not
have any plans to allow user ordering of controllers via .config, only
via editting the Makefile.  The plan is to clean up the Makefiles
first, introducing new facilities comes later (if ever).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Helge Hafting]

Jeremy Higdon wrote:
[...]
> My system has both an Adaptec adapter and a Qlogic adapter.  The number of
> disks on the Qlogic was variable (it was attached to a SAN).  The boot
> disk is attached to the Adaptec.  If the Qlogic was probed first, then
> linux could not find the root device, so I had to move the Adaptec 7xxx
> above the Qlogic in hosts.c.
> 
> Is there another way to do this?  If so, I'd like to know.  If not, then
> we need the same configurability with the new scheme.
>
I have the same problem.  Boot from raid-1 on a Tekram LVD controller,
and have an
adaptec with an old cdrom and sometimes a disk too.  The adaptec
is detected first.
But there is an easy fix: Compile the boot controller into the kernel,
and let the other controller be modular.  Compiled-in controllers
always go before modular.

Ideally I'd like specifying controller order in menuconfig.  Perhaps a
"controller order" submenu in scsi, that display the default order
of the selected controllers.  The user can then change this.
I guess that is 2.5 stuff though.

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Jeremy Higdon]

On Sep 19, 10:35am, Eric Youngdale wrote:
> 
> OK, my guess is that we may need to do some tweaking to the Makefile.
> The basic idea is that you need to probe for hosts in a specific order.
> The reason for this is that some host adapters emulate other types of
> hardware.  For example, some Buslogic cards emulate Adaptec 1542.
> Typically in such cases you want the Buslogic driver to handle the card and
> not the 1542 driver (mainly for performance reasons - Leonard would probably
> have more to say about this).  There *may* be other instances where probing
> for one type of card can screw up another type of card, but I haven't heard
> of cases like this in some time now,
> 
> There are a handful of others - the comments in the initializer in
> hosts.c explain some of them.  I hope there are not others which people
> failed to document.
> 
> A second potential gotcha - for compiled in drivers, I think that
> low-level drivers should be initialized prior to upper level drivers.  The
> reason for this is that not all of the upper level drivers are capable of
> resizing the arrays on the fly (disk and cdrom are the two exceptions).
> Yes, cleaning this up is on the list of things to do (it got partly done for
> 2.4), but fixing this is a nasty problem that reaches it's bony fingers all
> the way up into some of the filesystems (essentially those stupid arrays in
> ll_rw_blk which are read without any type of spinlock protection).   The
> CONFIG_SD_EXTRA_DEVS parameter is used to pre-allocate room in the arrays
> for additional devices, so for systems with small numbers (< 40) of disks
> things may just happen to work.
> 
> For now, the trick should simply be to keep the upper level drivers at
> the end of the list of objects to be linked in so the initializers run last.
> Thus my gut tells me the correct link order should be:
> 
> 1) SCSI core.
> 2) low-level drivers (in same order as specified in hosts.c).
> 3) upper level drivers.
> 
> -Eric

My system has both an Adaptec adapter and a Qlogic adapter.  The number of
disks on the Qlogic was variable (it was attached to a SAN).  The boot
disk is attached to the Adaptec.  If the Qlogic was probed first, then
linux could not find the root device, so I had to move the Adaptec 7xxx
above the Qlogic in hosts.c.

Is there another way to do this?  If so, I'd like to know.  If not, then
we need the same configurability with the new scheme.

jeremy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Linus Torvalds]

On Wed, 20 Sep 2000, Torben Mathiasen wrote:
> 
> I can't seem to find a clean way of getting the drivers outside "drivers/scsi"
> to link _after_ the other low-level drivers. My linux Makefile abilities is
> limited though, so if someone with the knowledge would do what Eric requests
> above please. We will probaly have to move some thing around, and that would be a
> _bad_ move at this point I guess.

Note that ordering requirements are usually bad requirements. In many
cases it's probably best to just fix the problem that causes ordering
requirements in the first place.

So we don't need to do a "perfect" job on ordering. In fact, we probably
want to avoid ordering as much as possible - I'd rather fix the problems
that cause us to want to order thing than spending much time trying to
order stuff.

Some ordering is simple: making sure that newer drivers show up before
older drivers that can catch on compatibility stuff. Some other cases are
equally obvious: keeping the sort in pretty much the same order as the old
hosts.c file just to avoid having peoples disks being re-ordered if
somebody has multiple types of SCSI controllers. That's more of a "let's
be polite" thing.

But let's fix the real problems rather than hit our heads against the
ordering wall..

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Tue, Sep 19 2000, Eric Youngdale wrote:
 
> 1) SCSI core.
> 2) low-level drivers (in same order as specified in hosts.c).
> 3) upper level drivers.
> 
 
Okay, I've just spent a couple of hours browsing through the scsi code, 
compiling different configs, and trying to figure out what to do with
the Makefile stuff. 

I can't seem to find a clean way of getting the drivers outside "drivers/scsi"
to link _after_ the other low-level drivers. My linux Makefile abilities is
limited though, so if someone with the knowledge would do what Eric requests
above please. We will probaly have to move some thing around, and that would be a
_bad_ move at this point I guess.

Now as I see it we have a few things we also need to fix:

DMA-POOL:
Someone on lkm reported getting low on dma-pool memory when using scsi as
builtin. Now Eric, how big is the difference between the two cases (module vs.
builtin) in the old scsi code? We use the module case for allocating dma mem 
now. I guess the module case tries to alloc as little as possible in order to
not hit fragmentated mem?

INIT:
The initialization routines needs to be looked at. Because we use the module 
stuff, some information gets printed wrong, like  "scsi: 0 hosts" scrolling
down the screen for each host.

I begin to wonder if some of this _really_ is 2.5 stuff. If someone can come
up with a clean solution to the Makefile issue, we might pull it off. If 
we need to move the other scsi drivers (i2o, etc.) around I think we should
back off and do it nice and slow for 2.5. In this case we could revert to 
the point where sd/st/sr are modulized, and saving the core system for 2.5.

This is just IMHO, let me know what you think.

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanning changes break RAID autorun

[Michael Shields]

In article <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> [ Btw, has autorun ever worked with non-scsi devices?

Yes, with IDE disks at least.
-- 
Shields.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanning changes break RAID autorun

[Russell King]

Linus Torvalds writes:
> [ Btw, has autorun ever worked with non-scsi devices? They've mostly had
>   the new initialization order for a long time.. ]

Hmm, I hope it will do, since a 2.2.17 kernel with Ingos RAID patches
works, and it'd be a shame to break all those RAID root filesystems out
there for 2.4.

(says me who only got Ingo raid running on 2.2.17 a couple of days
ago on ARM). ;)
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanning changes break RAID autorun

[Matthew Kirkwood]

On Tue, 19 Sep 2000, Linus Torvalds wrote:

> > moving the software RAID drivers into drivers/md/,

> Make it so.

OK.  Apply the attached diff and then:

$ mv drivers/block/{md,raid{0,1,5},xor}.c drivers/md/

and all might be well.

The Config.in should probably move at some stage too.

I'm not very au-fait with the kernel build system (nor
makefiles in general) so I'm not sure it's 100% correct,
but it build and linked with my .config, so it can't be
all bad.

Matthew.


diff -ruN linux-2.4.0-test8/Makefile linux/Makefile
--- linux-2.4.0-test8/Makefile  Sun Sep 10 12:36:04 2000
+++ linux/Makefile  Tue Sep 19 17:40:20 2000
@@ -176,6 +176,7 @@
 DRIVERS-$(CONFIG_I2C) += drivers/i2c/i2c.o
 DRIVERS-$(CONFIG_PHONE) += drivers/telephony/telephony.a
 DRIVERS-$(CONFIG_ACPI_INTERPRETER) += drivers/acpi/acpi.o
+DRIVERS-$(CONFIG_BLK_DEV_MD) += drivers/md/mddev.o
 
 DRIVERS += $(DRIVERS-y)
 
diff -ruN linux-2.4.0-test8/drivers/Makefile linux/drivers/Makefile
--- linux-2.4.0-test8/drivers/Makefile  Sun Sep  3 19:35:31 2000
+++ linux/drivers/Makefile  Tue Sep 19 17:16:40 2000
@@ -12,7 +12,7 @@
 ALL_SUB_DIRS := $(SUB_DIRS) pci sgi ide scsi sbus cdrom isdn pnp i2o \
ieee1394 macintosh video dio zorro fc4 \
usb nubus tc atm pcmcia i2c telephony \
-   acpi mtd input
+   acpi mtd input md
 
 ifdef CONFIG_DIO
 SUB_DIRS += dio
@@ -128,6 +128,15 @@
 else
   ifeq ($(CONFIG_SCSI),m)
   MOD_SUB_DIRS += scsi
+  endif
+endif
+
+ifeq ($(CONFIG_BLK_DEV_MD),y)
+SUB_DIRS += md
+MOD_SUB_DIRS += md
+else
+  ifeq ($(CONFIG_BLK_DEV_MD),m)
+  MOD_SUB_DIRS += md
   endif
 endif
 
diff -ruN linux-2.4.0-test8/drivers/block/Makefile linux/drivers/block/Makefile
--- linux-2.4.0-test8/drivers/block/MakefileSun Sep  3 19:35:02 2000
+++ linux/drivers/block/MakefileTue Sep 19 17:45:30 2000
@@ -14,7 +14,7 @@
 
 O_TARGET := block.o
 
-export-objs:= ll_rw_blk.o blkpg.o loop.o DAC960.o md.o xor.o
+export-objs:= ll_rw_blk.o blkpg.o loop.o DAC960.o
 list-multi := lvm-mod.o
 lvm-mod-objs   := lvm.o lvm-snap.o
 
@@ -35,12 +35,6 @@
 obj-$(CONFIG_BLK_CPQ_DA)   += cpqarray.o
 obj-$(CONFIG_BLK_DEV_DAC960)   += DAC960.o
 obj-$(CONFIG_BLK_DEV_LVM)  += lvm-mod.o
-
-obj-$(CONFIG_BLK_DEV_MD)   += md.o
-obj-$(CONFIG_MD_LINEAR)+= linear.o
-obj-$(CONFIG_MD_RAID0) += raid0.o
-obj-$(CONFIG_MD_RAID1) += raid1.o
-obj-$(CONFIG_MD_RAID5) += raid5.o xor.o
 
 obj-$(CONFIG_BLK_DEV_NBD)  += nbd.o
 
diff -ruN linux-2.4.0-test8/drivers/md/Makefile linux/drivers/md/Makefile
--- linux-2.4.0-test8/drivers/md/Makefile   Thu Jan  1 01:00:00 1970
+++ linux/drivers/md/Makefile   Tue Sep 19 17:45:22 2000
@@ -0,0 +1,29 @@
+#
+# Makefile for the kernel software RAID drivers.
+#
+
+O_TARGET   := mddev.o
+SUB_DIRS   :=
+ALL_SUB_DIRS   :=
+MOD_SUB_DIRS   :=
+
+export-objs:= md.o xor.o
+
+obj-y  :=
+obj-m  :=
+obj-n  :=
+obj-   :=
+
+obj-$(CONFIG_BLK_DEV_MD)   += md.o
+obj-$(CONFIG_MD_LINEAR)+= linear.o
+obj-$(CONFIG_MD_RAID0) += raid0.o
+obj-$(CONFIG_MD_RAID1) += raid1.o
+obj-$(CONFIG_MD_RAID5) += raid5.o xor.o
+
+# Translate to Rules.make lists.
+O_OBJS := $(filter-out $(export-objs), $(obj-y))
+OX_OBJS:= $(filter $(export-objs), $(obj-y))
+M_OBJS := $(sort $(filter-out $(export-objs), $(obj-m)))
+MX_OBJS:= $(sort $(filter  $(export-objs), $(obj-m)))
+
+include $(TOPDIR)/Rules.make

Re: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Tue, Sep 19 2000, Alan Cox wrote:
> > Thus my gut tells me the correct link order should be:
> > 
> > 1) SCSI core.
> > 2) low-level drivers (in same order as specified in hosts.c).
> > 3) upper level drivers.
> 
> You need to get the i2o scsi driver run last afte the low level and before
> the high level drivers despite being in drivers/i2o. There are some other
> drivers which arent in drivers/scsi too 
>

Did anyone start to cook up a patch for this? Otherwise I'll take look tonight.
(which is now, BTW.)


-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanning changes break RAID autorun

[Linus Torvalds]

On Tue, 19 Sep 2000, Matthew Kirkwood wrote:
> 
> It's probably solely an init-order thing but, short of
> moving the software RAID drivers into drivers/md/, I
> can't see an easy way to fix it.

That would probably not be a bad fix - especially as some people want to
split up xor.c into multiple files and I'd hate to clutter up
drivers/block any more than necessary anyway.

Make it so.

[ Btw, has autorun ever worked with non-scsi devices? They've mostly had
  the new initialization order for a long time.. ]

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Alan Cox]

> Thus my gut tells me the correct link order should be:
> 
> 1) SCSI core.
> 2) low-level drivers (in same order as specified in hosts.c).
> 3) upper level drivers.

You need to get the i2o scsi driver run last afte the low level and before
the high level drivers despite being in drivers/i2o. There are some other
drivers which arent in drivers/scsi too 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Eric Youngdale]

OK, my guess is that we may need to do some tweaking to the Makefile.
The basic idea is that you need to probe for hosts in a specific order.
The reason for this is that some host adapters emulate other types of
hardware.  For example, some Buslogic cards emulate Adaptec 1542.
Typically in such cases you want the Buslogic driver to handle the card and
not the 1542 driver (mainly for performance reasons - Leonard would probably
have more to say about this).  There *may* be other instances where probing
for one type of card can screw up another type of card, but I haven't heard
of cases like this in some time now,

There are a handful of others - the comments in the initializer in
hosts.c explain some of them.  I hope there are not others which people
failed to document.

A second potential gotcha - for compiled in drivers, I think that
low-level drivers should be initialized prior to upper level drivers.  The
reason for this is that not all of the upper level drivers are capable of
resizing the arrays on the fly (disk and cdrom are the two exceptions).
Yes, cleaning this up is on the list of things to do (it got partly done for
2.4), but fixing this is a nasty problem that reaches it's bony fingers all
the way up into some of the filesystems (essentially those stupid arrays in
ll_rw_blk which are read without any type of spinlock protection).   The
CONFIG_SD_EXTRA_DEVS parameter is used to pre-allocate room in the arrays
for additional devices, so for systems with small numbers (< 40) of disks
things may just happen to work.

For now, the trick should simply be to keep the upper level drivers at
the end of the list of objects to be linked in so the initializers run last.
Thus my gut tells me the correct link order should be:

1) SCSI core.
2) low-level drivers (in same order as specified in hosts.c).
3) upper level drivers.

-Eric

- Original Message -
From: "Linus Torvalds" <[EMAIL PROTECTED]>
To: "Torben Mathiasen" <[EMAIL PROTECTED]>; "Russell King" <[EMAIL PROTECTED]>
Cc: "Eric Youngdale" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, September 18, 2000 6:58 PM
Subject: Re: [PATCH] Re: SCSI scanning


>
> Ok, there's a test9-pre3 there now..
>
> The SCSI stuff is pretty straightforward, and it works for me (and I also
> built a kernel with all regular x86-capable SCSI drivers included, so the
> others got at least that level of testing). But there are some non-x86
> scsi drivers out there etc, so give it a whirl.
>
> Basic approach: remove all #ifdef MODULE, and get rid of the hosts.c
> hardcoded listing of SCSI devices - let SCSI controller drivers do their
> own initialization.
>
> Linus
>
> 
>  - pre1:
> - USB: OHCI controller unlink and bandwidth reclamation fixes
> - USB: storage update
> - sparc64: register window race. Non-deadlock rwlocks.
> - name clash in hamradio/pi2.c and hamradio/pt.c
> - epic100 credits, 8139too driver update, sr.c initcalls
> - acenic update
> - NFS sillyrename fixups
> - mktime(). Do it just once - not 16 times.
> - misc small fixes to random drivers by Tigran
> - IDE driver picks up master/slave relationships on its own.
> - truncate unmapped/uptodate case handled correctly
> - don't do notifier locking at low level: higher levels do (or
>   should do) this already.
> - ACPI interpreter updates (and file renames - making this part big)
> - SysKonnect gigabit driver update
> - 3c59x driver update
> - pcmcia debounce logic. Ugh.
> - MM balancing (Rik Riel)
>  - pre2:
> - "extern inline" -> "static inline".  It doesn't matter right now,
>   but it's proactive for future gcc versions.
> - various net drvr updates and fixes
> - more initcall updates
> - PPC updates (including PPC-related drivers etc)
> - disallow re-mounting same filesystem in same place multiple times.
>   Too confusing. And /etc/mtab gets strange.
> - Riel VM update
> - sparc updates
> - PCI bridge scanning fix: assign numbers properly
> - network updates
> - scsi fixes
>  - pre3:
> - uninitialized == zero. Remove extra initializers.
> - block_prepare_write and block_truncate_page: if the page is
>   up-to-date, then so are the buffer heads inside it once they
>   are mapped..
> - SCSI initialization - move over to the modular case. No more
>   double initialization.
> - Sync up with Alans 2.2.x driver changes
> - networking updates (iipv6 works non-modular etc)
> - netfilter update
> - adfs correct dentry operations
> - ARM update (i

Re: [PATCH] Re: SCSI scanning

[Rogier Wolff]

Jeff Garzik wrote:
> Helge Hafting wrote:
> > 
> > Rogier Wolff wrote:
> > [...]
> > > No, that's not it. They parse /proc/pci or the output of lspci to
> > > determine which module to insert.
> > 
> > Faster, and fine for pci-scsi.  I believe you still need
> > to testload modules for isa-scsi.
> 
> When PCI probing fails, the user is often presented with a list of
> possible drivers, and given the option of manually selecting their
> driver (including possible autoprobing).

Indeed. If I remember correctly an "autoprobe" for a CDROM device was
able to tickle a network card into jamming the ethernet (BNC era).
Stuff like that.

Jamming as in: no packet comes through! Imagine that happening every
time someone tries to install Linux.

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
*   Common sense is the collection of*
**  prejudices acquired by age eighteen.   -- Albert Einstein 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Jeff Garzik]

Helge Hafting wrote:
> 
> Rogier Wolff wrote:
> [...]
> > No, that's not it. They parse /proc/pci or the output of lspci to
> > determine which module to insert.
> 
> Faster, and fine for pci-scsi.  I believe you still need
> to testload modules for isa-scsi.

When PCI probing fails, the user is often presented with a list of
possible drivers, and given the option of manually selecting their
driver (including possible autoprobing).

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Helge Hafting]

Rogier Wolff wrote:
[...]
> No, that's not it. They parse /proc/pci or the output of lspci to
> determine which module to insert.

Faster, and fine for pci-scsi.  I believe you still need 
to testload modules for isa-scsi.  

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Rogier Wolff]

Linus Torvalds wrote:
> > Maybe nobody ever insmod'ed a module for a scsi device they don't
> > have?
> 
> No, that's not it - the way most distributions do SCSI auto-detection is
> to load modules until they succeed.

> At least I _think_ that's what they do. That's what I'd do if I were a
> distribution maker.

No, that's not it. They parse /proc/pci or the output of lspci to
determine which module to insert. 

At least I _think_ that's what they do. Not that I'd do it differently
from you if I were a distribution maker.

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
*   Common sense is the collection of*
**  prejudices acquired by age eighteen.   -- Albert Einstein 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Linus Torvalds]

On Mon, 18 Sep 2000, Olivier Galibert wrote:

> On Mon, Sep 18, 2000 at 05:51:43PM -0700, Linus Torvalds wrote:
> > Why would this not have happened for a module?
> > 
> > I agree that the thing looks fishy. But this is not new code, and it has
> > worked previously. What changed?
> 
> Maybe nobody ever insmod'ed a module for a scsi device they don't
> have?

No, that's not it - the way most distributions do SCSI auto-detection is
to load modules until they succeed.

At least I _think_ that's what they do. That's what I'd do if I were a
distribution maker.

Anyway, I fixed this one up (untested), and fixed another thing that would
cause modules to not get the version information correctly, and made a
pre4. Whatever the cause for it not having been noticed before, it was a
bug. And it should be gone. Good.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Olivier Galibert]

On Mon, Sep 18, 2000 at 05:51:43PM -0700, Linus Torvalds wrote:
> Why would this not have happened for a module?
> 
> I agree that the thing looks fishy. But this is not new code, and it has
> worked previously. What changed?

Maybe nobody ever insmod'ed a module for a scsi device they don't
have?

  OG.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Linus Torvalds]

On Mon, 18 Sep 2000, David S. Miller wrote:
> 
> The problem is that regardless of the tpnt->present setting, the
> MOD_DEC_USE_COUNT must occur.
> 
>And again, why did this not show up with modules? 
> 
> I have no idea, I'm just the messenger in this case :-)

Hey, I didn't shoot you, I just want somebody from the SCSI camp to say
something.

Can you test whether changing the

if (tpnt->present)
return;

to a

if (tpnt->present) {

.. indent the linked list code and the remove_proc_entry stuff ..
}

fixes the oops for you?

> The boot logs looked something like (note the request_module messages,
> wheee...):

That "request_module[]: Root fs not mounted" message is going to get a lot
more common (and actually get removed) - there's a lot of stuff where we
want to exec a user mode helper, but where the bootup case is special. So
igore that - it's going away, by virtue of making the printk() disappear
;)

> SCSI device sdb: hdwr sector= 512 bytes. Sectors= 4194995 [2048 MB] [2.0 GB]
>  sdb: sdb1 sdb2 sdb3
> ...
> scsi : 2 hosts.
> 
> And precisely here is where the OOPS was seen.

Yeah, it's just after the ESP case, getting ready to do the ncr case..
Which will be silent due to not having any controller - until it oopses on
you.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[David S. Miller]

   Date: Mon, 18 Sep 2000 17:51:43 -0700 (PDT)
   From: Linus Torvalds <[EMAIL PROTECTED]>

   Umm, reading the code it looks more like the proper test would be

   if (!tpnt->present)
   return;

   because if "present == 0", then the host not only won't have had the proc
   entry added, it also won't have been added to the "scsi_hosts" list - so
   the "remove the adapter from the linked list" step is the wrong way around
   too. No?

The problem is that regardless of the tpnt->present setting, the
MOD_DEC_USE_COUNT must occur.

   And again, why did this not show up with modules? 

I have no idea, I'm just the messenger in this case :-)
My situation was:

1) esp.c sym53c8xx.c statically built into kernel
2) I have 2 esp interfaces present in this machine,
   none for the sym53c8xx driver.

The boot logs looked something like (note the request_module messages,
wheee...):

request_module[scsi_hostadapter]: Root fs not mounted
esp0: IRQ 3,7e0 SCSI ID 7 Clk 40MHz CCYC=25000 CCF=8 TOut 167 NCR53C9XF(espfast)
esp1: IRQ 7,7db SCSI ID 7 Clk 40MHz CCYC=25000 CCF=8 TOut 167 NCR53C9XF(espfast)
ESP: Total of 2 ESP hosts found, 2 actually in use.
scsi0 : Sparc ESP366-HME
scsi1 : Sparc ESP366-HME
scsi : 2 hosts.
...
Partition check:
 sda: sda1 sda2 sda3
esp0: target 1 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 4194995 [2048 MB] [2.0 GB]
 sdb: sdb1 sdb2 sdb3
...
scsi : 2 hosts.

And precisely here is where the OOPS was seen.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Linus Torvalds]

On Mon, 18 Sep 2000, David S. Miller wrote:
> 
> Did you try to boot these kernels containing scsi devices you
> don't have?  I don't see how it could work (actually I do, see
> below).

Hmm..

Why would this not have happened for a module?

I agree that the thing looks fishy. But this is not new code, and it has
worked previously. What changed?

> Anyways, the code at the end of scsi_unregister_host should rather
> be something like:
> 
>   if (tpnt->present) {
>   remove_proc_entry(tpnt->proc_name, proc_scsi);
>   return;
>   }

Umm, reading the code it looks more like the proper test would be

if (!tpnt->present)
return;

because if "present == 0", then the host not only won't have had the proc
entry added, it also won't have been added to the "scsi_hosts" list - so
the "remove the adapter from the linked list" step is the wrong way around
too. No?

(That linked list implementation, btw, is the worst possible list
implementation I have ever seen. Ugh).

And again, why did this not show up with modules? 

Curious.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[David S. Miller]

   Date:Mon, 18 Sep 2000 15:58:02 -0700 (PDT)
   From: Linus Torvalds <[EMAIL PROTECTED]>

   The SCSI stuff is pretty straightforward, and it works for me (and
   I also built a kernel with all regular x86-capable SCSI drivers
   included, so the others got at least that level of testing). But
   there are some non-x86 scsi drivers out there etc, so give it a
   whirl.

Did you try to boot these kernels containing scsi devices you
don't have?  I don't see how it could work (actually I do, see
below).

Look at drivers/scsi/scsi.c:scsi_unregister_host, near the
end we have code like this:

if (tpnt->present)
return;

...

remove_proc_entry(tpnt->proc_name, proc_scsi);

Compare this to the code in scsi_register_host which explicitly
does not create the procfs nodes if tpnt->present == 0.

Is this another case of ix86 not trapping NULL pointer derefernces
during bootup?  I got it on Sparc in strlen of tpnt->proc_name
as a result of this remove_proc_entry() call.  Is there some way
to make ix86 start trapping on NULL pointers earlier in the boot
sequence so these kinds of bugs don't live very long?

Anyways, the code at the end of scsi_unregister_host should rather
be something like:

if (tpnt->present) {
remove_proc_entry(tpnt->proc_name, proc_scsi);
return;
}

...

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

This will probaly fix a bunch of scsi problems in tytso's list at 
linux24.sourceforge.net.
Could people please verify this and send him a note. 

Thanks.

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Linus Torvalds]

Ok, there's a test9-pre3 there now..

The SCSI stuff is pretty straightforward, and it works for me (and I also
built a kernel with all regular x86-capable SCSI drivers included, so the
others got at least that level of testing). But there are some non-x86
scsi drivers out there etc, so give it a whirl.

Basic approach: remove all #ifdef MODULE, and get rid of the hosts.c
hardcoded listing of SCSI devices - let SCSI controller drivers do their
own initialization.

Linus


 - pre1:
- USB: OHCI controller unlink and bandwidth reclamation fixes
- USB: storage update
- sparc64: register window race. Non-deadlock rwlocks.
- name clash in hamradio/pi2.c and hamradio/pt.c  
- epic100 credits, 8139too driver update, sr.c initcalls
- acenic update
- NFS sillyrename fixups
- mktime(). Do it just once - not 16 times.
- misc small fixes to random drivers by Tigran
- IDE driver picks up master/slave relationships on its own.
- truncate unmapped/uptodate case handled correctly
- don't do notifier locking at low level: higher levels do (or
  should do) this already. 
- ACPI interpreter updates (and file renames - making this part big)
- SysKonnect gigabit driver update
- 3c59x driver update
- pcmcia debounce logic. Ugh.
- MM balancing (Rik Riel)
 - pre2:
- "extern inline" -> "static inline".  It doesn't matter right now,
  but it's proactive for future gcc versions.
- various net drvr updates and fixes
- more initcall updates
- PPC updates (including PPC-related drivers etc)
- disallow re-mounting same filesystem in same place multiple times.
  Too confusing. And /etc/mtab gets strange.
- Riel VM update
- sparc updates
- PCI bridge scanning fix: assign numbers properly
- network updates
- scsi fixes
 - pre3:
- uninitialized == zero. Remove extra initializers.
- block_prepare_write and block_truncate_page: if the page is
  up-to-date, then so are the buffer heads inside it once they
  are mapped..
- SCSI initialization - move over to the modular case. No more
  double initialization.
- Sync up with Alans 2.2.x driver changes
- networking updates (iipv6 works non-modular etc)
- netfilter update
- adfs correct dentry operations
- ARM update (including ARM drivers)
- acenic driver update
- floppy: we'd better hold the io_request_lock when playing with "CURRENT".
- NFS cache coherency across file locking fix
- NFS over TCP - handle TCP socket writability right..
- USB updates

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Mon, Sep 18 2000, Torben Mathiasen wrote:
> It just hit me when I touched the send button (yeah right!). I'm basicly 
> compiling the same kernel right now. 
> Glad we got that in place, otherwise it would have been a long wasted night 8).
>

And just to follow up on my own mail, this patch works great. This has to be one of
the cleanest module conversions I've seen in a while. Although it _will_ require a 
minor
change to all of the scsi drivers, the scsi_module.c implementation helps a lot.

At first I was sceptical about the scsi subsytem structure, but it turns out this _is_
what made it possible to do it cleanly, so kudos to Eric.

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Sven Koch]

On Mon, 18 Sep 2000, Mr. James W. Laferriere wrote:

>   Oh God ,  I hope this doesn't mean what I think it might ?
>   Please tell me I am stil going to be able to 'Statically' compile
>   in the drivers of my choosing ?  Tia ,  JimL

This discussion is about using one initialization scheme for compiled-in
and modules (the one currently used by modules), not about modules-only.

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Mr. James W. Laferriere]

On Mon, 18 Sep 2000, Torben Mathiasen wrote:

> On Mon, Sep 18 2000, Linus Torvalds wrote:
> > And think about it - if this part didn't work, then loadable SCSI modules
> > would never have worked. And every single distribution I know of basically
> > depends on SCSI drivers being loadable modules, because there are just too
> > effing many of them ;)
Oh God ,  I hope this doesn't mean what I think it might ?
Please tell me I am stil going to be able to 'Statically' compile
in the drivers of my choosing ?  Tia ,  JimL

 ...snip...

   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Mon, Sep 18 2000, Linus Torvalds wrote:
> And think about it - if this part didn't work, then loadable SCSI modules
> would never have worked. And every single distribution I know of basically
> depends on SCSI drivers being loadable modules, because there are just too
> effing many of them ;)
>

It just hit me when I touched the send button (yeah right!). I'm basicly 
compiling the same kernel right now. 
Glad we got that in place, otherwise it would have been a long wasted night 8).

> I'll make a test9-pre3 so that you can synch up, but I need to integrate
> all the 2.2.x stuff that Alan sent me yesterday first ;)
>

Excellent, people are starting to cry...

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Linus Torvalds]

On Mon, 18 Sep 2000, Torben Mathiasen wrote:
>
> What about the case when scsi is compiled into the kernel with one or
> more host adapters? We have to initialize those right away.

Actually, we don't. It's really equivalent to just having two or
more modules.

>Please
> explain what you did with all the host initialization (spin-up, etc.)
> in scsi_dev_init.

It's all gone.

Look at the module paths. They all do the same thing, except there it's
nicely per-controller. It's just hidden in scsi_module.c: the
scsi_register_module() thing will do it all for you.

So when yu remove the #ifdef MODULE logic from the controller driver code,
the spin-up and scanning still gets done - without any global help from
scsi_dev_init() at all.

And think about it - if this part didn't work, then loadable SCSI modules
would never have worked. And every single distribution I know of basically
depends on SCSI drivers being loadable modules, because there are just too
effing many of them ;)

I'll make a test9-pre3 so that you can synch up, but I need to integrate
all the 2.2.x stuff that Alan sent me yesterday first ;)

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Linus Torvalds]

On Mon, 18 Sep 2000, Eric Youngdale wrote:
>
> What is the primary objective here - getting rid of #ifdef MODULE, or is
> it removing redundant code for the two paths?  Or both?

Both. 

As you probably saw, it really started out from fixing this silly bug that
was introduced by mistake some time ago - which was due to both the module
init and the "built-in" init code kicking in. The fact that it wasn't
clear which happened where is really for me the driving force here - I'd
like to avoid the same bug cropping up in half a year when somebody cleans
up some low-level driver init.

Oh, and getting rid of the init list in hosts.c is a nice bonus. It just
goes away automatically if you look at the module init path instead ;)

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Mon, Sep 18 2000, Eric Youngdale wrote:
> What is the primary objective here - getting rid of #ifdef MODULE, or is
> it removing redundant code for the two paths?  Or both?
> 
> I am just trying to get a handle on what is driving this.

Well the code clean-up came as a pleasent side effect of removing
ifdef MODULE. But now it seems Linus has done it without this. I
think this is okay, as it gives us a _nice_ working scsi layer back,
on which we can build our cleanup.

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Mon, Sep 18 2000, Linus Torvalds wrote:
> Actually, hold off a moment.
> 
> It turns out that the MODULE case does all the right things, for all the
> obvious reasons. I'm running a kernel that has the #ifdef MODULE stuff
> just removed, and it seems to be a rather easy approach. It really only
> required making a few things static (the init routines would clash
> otherwise), and removing a lot of #ifdef MODULE.
> 
> (And removing some code that was enabled only for non-modules).
> 
> It looks very straightforward.
>

What about the case when scsi is compiled into the kernel with one or
more host adapters? We have to initialize those right away. Please
explain what you did with all the host initialization (spin-up, etc.)
in scsi_dev_init.

You could also just send me a diff, and I'll take a look.

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Eric Youngdale]

What is the primary objective here - getting rid of #ifdef MODULE, or is
it removing redundant code for the two paths?  Or both?

I am just trying to get a handle on what is driving this.

-Eric

- Original Message -
From: "Linus Torvalds" <[EMAIL PROTECTED]>
To: "Torben Mathiasen" <[EMAIL PROTECTED]>
Cc: "Eric Youngdale" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, September 18, 2000 4:43 PM
Subject: Re: [PATCH] Re: SCSI scanning


>
>
> On Mon, 18 Sep 2000, Torben Mathiasen wrote:
> >
> > Thanks a lot. I've started to do the basics, like getting all subsystems
to work
> > with the module_init/exit stuff. This of course leds to some
rewriteting/restructuring
> > of the scsi layer. Nothing major though.
>
> Actually, hold off a moment.
>
> It turns out that the MODULE case does all the right things, for all the
> obvious reasons. I'm running a kernel that has the #ifdef MODULE stuff
> just removed, and it seems to be a rather easy approach. It really only
> required making a few things static (the init routines would clash
> otherwise), and removing a lot of #ifdef MODULE.
>
> (And removing some code that was enabled only for non-modules).
>
> It looks very straightforward.
>
> Linus
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Linus Torvalds]

On Mon, 18 Sep 2000, Torben Mathiasen wrote:
> 
> Thanks a lot. I've started to do the basics, like getting all subsystems to work
> with the module_init/exit stuff. This of course leds to some 
>rewriteting/restructuring
> of the scsi layer. Nothing major though.

Actually, hold off a moment.

It turns out that the MODULE case does all the right things, for all the
obvious reasons. I'm running a kernel that has the #ifdef MODULE stuff
just removed, and it seems to be a rather easy approach. It really only
required making a few things static (the init routines would clash
otherwise), and removing a lot of #ifdef MODULE.

(And removing some code that was enabled only for non-modules).

It looks very straightforward.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Mon, Sep 18 2000, Eric Youngdale wrote:
> Historical.  SCSI was made modular very early on when the modules
> technology was pretty primative.  As time has gone on, the two
> initialization paths have converged, and now they are essentially redundant.
>

Thats understandable.

> The one thing that is different in the module/non-module case is for the
> case of SCSI compiled into the kernel, you need to look at the list of
> compiled-in host adapters.  Unless of course you are cleaning that up as
> well.  I haven't seen the threads that got this work started, and it is only
> in reading this morning's messages that I see the rationale for all these
> changes in the first place.  There are a couple of ways of addressing this,
> some better than others, and some are more work than others.  I can give you
> assistance and ideas if you want.
>

Thanks a lot. I've started to do the basics, like getting all subsystems to work
with the module_init/exit stuff. This of course leds to some rewriteting/restructuring
of the scsi layer. Nothing major though.

It seems I can't avoid some of the ifdef MODULE stuff in the initialization routines
in scsi.c, exactly because of the issues you mention (init builtin host adapters when
scsi is also builtin)

Let me know if you have any hints as what should be looked at while we are
at it. I'll send you a patch soon for your comments.


-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Eric Youngdale]

- Original Message -
From: "Linus Torvalds" <[EMAIL PROTECTED]>
To: "Torben Mathiasen" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, September 17, 2000 9:32 PM
Subject: Re: [PATCH] Re: SCSI scanning


>
>
> On Sun, 17 Sep 2000, Linus Torvalds wrote:
> >
> > This is the patch I was looking for. Thanks,
>
> Oh, grepping some more for scsi initializations, the "scsi_dev_init()"
> thing stands out.
>
> That's another case where the SCSI layer is module dependent. If it's a
> module, we use the "init_module()" in scsi/scsi.c, and if not, we instead
> use "scsi_dev_init()". They do some of the same things (well, they
> obviously would have to, otherwise there wouldn't be any point to having a
> init routine at all), but in general do it in very different ways for no
> good reason I can see.
>
> Torben, would you mind terribly expanding on your previous patch a bit,
> and also cleaning this part up? As far as I can tell, we should just
> remove scsi_dev_init() completely, and use the module init code with an
> initcall(). Two less regions of #ifdef MODULE, and one less different
> code-path to worry about..
>
> Why was this done this way anyway? I've never seen this kind of setup in
> any of the other drivers that have been de-liced of module dependencies..

Historical.  SCSI was made modular very early on when the modules
technology was pretty primative.  As time has gone on, the two
initialization paths have converged, and now they are essentially redundant.

The one thing that is different in the module/non-module case is for the
case of SCSI compiled into the kernel, you need to look at the list of
compiled-in host adapters.  Unless of course you are cleaning that up as
well.  I haven't seen the threads that got this work started, and it is only
in reading this morning's messages that I see the rationale for all these
changes in the first place.  There are a couple of ways of addressing this,
some better than others, and some are more work than others.  I can give you
assistance and ideas if you want.

-Eric


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning]

[Torben Mathiasen]

> On Sun, 17 Sep 2000, Linus Torvalds wrote:
> That's another case where the SCSI layer is module dependent. If it's a
> module, we use the "init_module()" in scsi/scsi.c, and if not, we instead
> use "scsi_dev_init()". They do some of the same things (well, they
> obviously would have to, otherwise there wouldn't be any point to having a
> init routine at all), but in general do it in very different ways for no
> good reason I can see.
>

I agree. The scsi subsystem has been like this for ages, and I've 
taken the task of cleaning it up.  The reason for not doing the 
_big_ patch right away, was because of the complextity of this
paticular layer. This complexity is _not_ needed, as the recent
changes to the network layer has taught us. In fact I think 
making the scsi layer behave more like the network layer 
in terms of initialization would benefit not only those hacking
on scsi, but all of those maintaining scsi host drivers. 

> Torben, would you mind terribly expanding on your previous patch a bit,
> and also cleaning this part up? As far as I can tell, we should just
> remove scsi_dev_init() completely, and use the module init code with an
> initcall(). Two less regions of #ifdef MODULE, and one less different
> code-path to worry about..
> 

I'll do this. I agree about the scsi_dev_init part. We _need_ one entry
point into each module (scsi/host/device). This change will actually
make some code a duplicate and therefore needs to be removed which
I consider a good ting. 


-- 
Regards,
Torben Mathiasen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanning

[Michael Elizabeth Chastain]

The exact semantics are:

.config:

CONFIG_FOO=y# yes

CONFIG_FOO=m# module

# CONFIG_FOO is not set # no

include/linux/autoconf.h:

#define CONFIG_FOO 1/* yes */

#undef CONFIG_FOO   /* module */
#define CONFIG_FOO_MODULE 1 /* module */

#undef CONFIG_FOO   /* no */

So anything in C code that tests for CONFIG_FOO is going to be true
if FOO is configured 'yes' and false if FOO is configured 'module'.

I think some kernel code suffers from a misapprehension that CONFIG_FOO
is enabled for both 'yes' and 'module'.  It's only enabled for 'yes'.

Michael Elizabeth Chastain

"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] Re: SCSI scanning

[Torben Mathiasen]

On Sun, Sep 17 2000, Jan Niehusmann wrote:
> 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.
> 
> #ifdef CONFIG_BLK_DEV_SD
> scsi_register_device(&sd_template);
> #endif
>

I've attached a patch that seems to do "The Right Thing". The problem was
that the host detection routines would initialize the upper layers of scsi
drivers (sd/st/sr), and then the module_init routines would
do it again. I've removed this so now all device initialization is
done through the module_init stuff. Now this change has required all upper
layers to use this init method, and the patch therefore also updates st.

I've done some testing the last few hours with different configs to be sure 
nothing breaks, but to be absolutely sure I've CC'ed Eric to verify. This 
change makes the upper layers initialize a litte later when the initcall 
functions are called. 

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk


diff -ur --exclude-from=/root/torben linux-2.4.0-test9p2/drivers/scsi/hosts.c 
linux/drivers/scsi/hosts.c
--- linux-2.4.0-test9p2/drivers/scsi/hosts.cTue Jul 11 20:17:45 2000
+++ linux/drivers/scsi/hosts.c  Sun Sep 17 21:28:35 2000
@@ -11,6 +11,10 @@
  *  Jiffies wrap fixes (host->resetting), 3 Dec 1998 Andrea Arcangeli
  *  Added QLOGIC QLA1280 SCSI controller kernel host support. 
  * August 4, 1999 Fred Lewis, Intel DuPont
+ *
+ *  Updated to reflect the new initialization scheme for the higher 
+ *  level of scsi drivers (sd/sr/st)
+ *  September 17, 2000 Torben Mathiasen <[EMAIL PROTECTED]>
  */
 
 
@@ -998,20 +1002,7 @@
 printk ("scsi : %d host%s.\n", next_scsi_host,
(next_scsi_host == 1) ? "" : "s");
 
-/* Now attach the high level drivers */
-#ifdef CONFIG_BLK_DEV_SD
-scsi_register_device(&sd_template);
-#endif
-#ifdef CONFIG_BLK_DEV_SR
-scsi_register_device(&sr_template);
-#endif
-#ifdef CONFIG_CHR_DEV_ST
-scsi_register_device(&st_template);
-#endif
-#ifdef CONFIG_CHR_DEV_SG
-scsi_register_device(&sg_template);
-#endif
-
+
 #if 0  
 max_scsi_hosts = next_scsi_host;
 #endif
diff -ur --exclude-from=/root/torben linux-2.4.0-test9p2/drivers/scsi/sd.c 
linux/drivers/scsi/sd.c
--- linux-2.4.0-test9p2/drivers/scsi/sd.c   Sun Sep 17 21:23:48 2000
+++ linux/drivers/scsi/sd.c Sun Sep 17 21:26:46 2000
@@ -1335,13 +1335,13 @@
return;
 }
 
-static int init_sd(void)
+static int __init init_sd(void)
 {
sd_template.module = THIS_MODULE;
return scsi_register_module(MODULE_SCSI_DEV, &sd_template);
 }
 
-static void exit_sd(void)
+static void __exit exit_sd(void)
 {
struct gendisk **prev_sdgd_link;
struct gendisk *sdgd;
diff -ur --exclude-from=/root/torben linux-2.4.0-test9p2/drivers/scsi/st.c 
linux/drivers/scsi/st.c
--- linux-2.4.0-test9p2/drivers/scsi/st.c   Wed Sep  6 21:53:14 2000
+++ linux/drivers/scsi/st.c Sun Sep 17 21:27:12 2000
@@ -3700,9 +3700,7 @@
 }
 
 
-#ifdef MODULE
-
-int __init init_module(void)
+static int __init init_st(void)
 {
validate_options();
 
@@ -3710,7 +3708,7 @@
 return scsi_register_module(MODULE_SCSI_DEV, &st_template);
 }
 
-void cleanup_module(void)
+static void __exit exit_st(void)
 {
int i;
 
@@ -3736,4 +3734,6 @@
st_template.dev_max = 0;
printk(KERN_INFO "st: Unloaded.\n");
 }
-#endif /* MODULE */
+
+module_init(init_st);
+module_exit(exit_st);

Re: [PATCH] Re: SCSI scanning

[Jeff Garzik]

Linus Torvalds wrote:
> Torben, would you mind terribly expanding on your previous patch a bit,
> and also cleaning this part up? As far as I can tell, we should just
> remove scsi_dev_init() completely, and use the module init code with an
> initcall(). Two less regions of #ifdef MODULE, and one less different
> code-path to worry about..
> 
> Why was this done this way anyway? I've never seen this kind of setup in
> any of the other drivers that have been de-liced of module dependencies..

In my experience most of the code differences between builtin and module
wind up being due to historical differences between the two in other
code layers, and the driver has to take that into account.

ISA net drivers are similar...  they do different types of probing and
initialization depending on ifdef MODULE, but those differences can be
eliminated for the most part just by using modern APIs..

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Linus Torvalds]

On Sun, 17 Sep 2000, Linus Torvalds wrote:
> 
> This is the patch I was looking for. Thanks,

Oh, grepping some more for scsi initializations, the "scsi_dev_init()"
thing stands out.

That's another case where the SCSI layer is module dependent. If it's a
module, we use the "init_module()" in scsi/scsi.c, and if not, we instead
use "scsi_dev_init()". They do some of the same things (well, they
obviously would have to, otherwise there wouldn't be any point to having a
init routine at all), but in general do it in very different ways for no
good reason I can see.

Torben, would you mind terribly expanding on your previous patch a bit,
and also cleaning this part up? As far as I can tell, we should just
remove scsi_dev_init() completely, and use the module init code with an
initcall(). Two less regions of #ifdef MODULE, and one less different
code-path to worry about..

Why was this done this way anyway? I've never seen this kind of setup in
any of the other drivers that have been de-liced of module dependencies..

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: SCSI scanning

[Linus Torvalds]

On Sun, 17 Sep 2000, Torben Mathiasen wrote:
> 
> I've attached a patch that seems to do "The Right Thing". The problem was
> that the host detection routines would initialize the upper layers of scsi
> drivers (sd/st/sr), and then the module_init routines would
> do it again. I've removed this so now all device initialization is
> done through the module_init stuff. Now this change has required all upper
> layers to use this init method, and the patch therefore also updates st.

Looks good, and cleans up the code.

I _also_ suspect that this change should mean that all of the templates
should become local objects, and that we should thus make sd_template,
sr_template and st_template be static to their own files. As far as I can
tell, there is no reason to export them - they were only exported due to
the extra initialization.

> I've done some testing the last few hours with different configs to be sure 
> nothing breaks, but to be absolutely sure I've CC'ed Eric to verify. This 
> change makes the upper layers initialize a litte later when the initcall 
> functions are called. 

Note that if this breaks, then the module case must have been broken
already, so I'd call this a fairly safe change, in addition to cleaning
the code up. The only thing to look out for is linking order (which is the
same as "module load order" for a module), and sd.o, st.o and sr.o are all
linked at the top as far as I can see.

This is the patch I was looking for. Thanks,

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanning

[Linus Torvalds]

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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanning

[Jan Niehusmann]

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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanning

[Linus Torvalds]

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.

I don't like it that modules behave differently from built-in. You're
suggesting I make them even _more_ different, so that the end result would
be similar. I'd like to know why we cannot just make them the exact same
logic, and not break it more.

Basically, there has to be some other place that does the equivalent of

if (!module) init_subsystems();

and I don't see why we can't just remove that one and make modules and
compiled-in behave the same.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SCSI scanning

[Torben Mathiasen]

On Sat, Sep 16 2000, Jan Niehusmann wrote:
> test9-pre1 does not contain a fix for the test8 scsi scanning problem. SCSI
> disks are detected twice if scsi is not compiled as a module. Torben already
> posted a patch.
>

Linus,

The proper way of fixing this is to add #ifdef MODULE around the init
functions or going back to init/exit_module. 
I know it looks ugly, but because of the structure of the 
scsi subsytem this is the only way out besides doing a nasty hack
to scsi.c. And even with the hack, the initialisation functions
will get called twice which is wrong.

I guess the scsi subsystem is in need of an overhaul for 2.5.

Patches have already been sent to you for sd (me) and sr (Jens Axboe).



-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/