----- Original Message -----
From: "Linus Torvalds" <torvalds@transmeta.com>
To: "Torben Mathiasen" <tmm@image.dk>
Cc: "Eric Youngdale" <eric@andante.org>; <jan@gondor.com>;
<linux-kernel@vger.kernel.org>; <linux-scsi@vger.kernel.org>
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/<platform>/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 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:24 EST