Messages in this thread |  | | Date | Fri, 22 Sep 2000 01:10:44 -0500 | Subject | Re: [PATCH] Re: SCSI scanning | From | 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |