[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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:26 EST