Messages in this thread |  | | From | "Eric Youngdale" <> | Subject | Re: [PATCH] Re: SCSI scanning | Date | Wed, 20 Sep 2000 16:48:56 -0400 |
| |
----- 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/
|  |