On Wed, Sep 15, 2004 at 05:28:22PM +0200, Harald Dunkel wrote: > > >The right solution in general is to establish a way to get the list of > >SCSI drivers loaded in the system sorted in the order by which they > >were loaded. > > This sequence is written down nowhere, AFAIK, so there is nothing > to get.
It is (was) written down in /proc/scsi. The ordering of the subdirectories correspond directly to their load order. The ordering in /proc/modules is fine as well, except that you need to reverse it. However, /proc/modules is fundamentally broken because it prevents someone from installing an initrd kernel while running a kernel with the driver built-in. > Probably you would agree that it is sufficient to generate the > same load sequence for all IDE, SCSI, and SATA devices on each > reboot. If all these modules are loaded by the initrd boot script, > then this sequence is completely under control of the initrd-tools, > regardless of the module load history of the currently running > kernel. You can't assume that they are all loaded by the initrd. You must consider users with the drivers built-in as well users who load modules after root has been mounted. How else is someone going to install an initrd kernel while running a non-initrd kernel? > The scsi modules found via /proc/modules are _appended_ to > the list of modules found so far. The sequence of modules > found before mkinitrd looked into /proc/modules is not changed. > It doesn't get worse, AFAICS. ALATBSOL. This is broken. For example, on a machine that boots of SATA while also having another SCSI card with a disk attached, doing this will cause the non-SATA SCSI disk to become /dev/sda. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
