> > The BIOS probe order is different from machine to machine or even from BIOS
> > release to BIOS release. The new PCI subsystem now always sorts the devices by
> > bus/device/function lexicographically, so you get the same order not depending
> > on whether you use the BIOS or not. The latest PCI patch I've sent to the list
> > adds an option to reverse the order to be compatible with 2.0.X.
>
> Why not keep the BIOS order. Its the order in every other OS you boot on the
> same machine, its an order available to you and it means little things like
> Lilo and the OS agree which bios disk is which linux disk.
>
> The change is utterly pointless. We should use BIOS order on a PC at least.
> BIOS order is the existing, normal and defacto ordering for such systems. Like
> it or not.
[cc: list trimmed]
This would make sense indeed if our initialization scheme were something
like:
scan PCI space in bios order
call drivers for each device as we find it
Unfortunately, this is not the case. For instance, I have a box with ncr
and buslogic scsi controllers which I can permute inside to get any of
them to be the boot controller. However, this makes no difference once the
kernel boots, because the buslogic driver will always be called before the
ncr driver (if they are both compiled in, of course).
This said, I totally agree that breaking compatibility with 2.0 for no
good reason is not the way to go. A few weeks ago I sent a message (and a
patch) to the list asking if the change in the ordering of the scsi
controllers in proc_fs.h between 2.0 and 2.1 was really necessary; nobody
bother to respond so I guess it wasn't. For one thing, it totally breaks a
system using Eric Youngdale's scsidev which is a must when there are many
scsi disks connected - booting with 2.1 will render a 2.0 fstab useless
and viceversa. I can send the patch again if somebody wants it..
Ionut
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu