Messages in this thread |  | | Date | Wed, 3 Jul 1996 11:02:36 -0700 | From | "Leonard N. Zubkoff" <> | Subject | Re: SCSI device numbering (was: Re: Ideas for v2.1 |
| |
Date: Wed, 3 Jul 1996 12:51:41 +0300 (EET DST) From: Linus Torvalds <torvalds@cs.Helsinki.FI>
Two comments: - we don't want to be think too much about PCI. Locking ourselves to a specific bus architecture is just plain bad - there is no reason for it, as the BUS details shouldn't be seen to user mode anyway (it makes _some_ sense to show SCSI ID/LUN details, because that is something that the user at least can care about).
I was not thinking too much about any one bus type such as PCI. What I was saying is that the bus type must be part of the identification, and then each bus type will specialize part of the remainder of the identifier. I presented examples of what would be required for PCI and ISA (and EISA).
- it's definitely WRONG to make a device number depend on the bus it's on. It's been done by others, but others have been plain stupid (or the target audience has been the setup where people religiously care about where they put their cards, which is definitely not true on PC's)
The reason it's WRONG to make device numbers depend on the bus is that we don't want the numbers for change for the _normal_ cases. And it's a lot more frequent that people have just one SCSI adapter and move that around (or exchange it for another) than people having multiple adapters and moving those around.
There's a very simple solution to this: we treat the boot (or any single) controller specially. Thus none of this bus-type/bus/device/function complexity would be present for all these simple PCs you are referring to above and below. It may be wrong for PCs, but I thought we weren't only interested in PCs any longer. It's not at all wrong in a machine with 201 disks arranged on 28 SCSI buses with 4 channels each on 7 controllers.
We can even handle the case of two controllers without the full complexity, since the boot controller is naturally distinguished, and therefore a second controller is inherently "non-boot". But once we get to three or more, I don't see how you can satisfy the goal I presented without considering the bus.
I can only conclude from this that you consider the goal itself as flawed and undesirable. I've shown how to handle the special cases of simple PCs that are bothering you while still satisfying the goal. Please explain how you would handle the complex case I've described, or argue that the goal itself is flawed.
If you encode any bus information in the device number, then you're just shooting yourself in the foot: if the card is moved (for example, the user installs a sound card, and wants to move the other cards around to make the ribbons fit better - I've done things like that many times) then the major number changes.
(I thought we were only talking about minor numbers here.)
Similarly, if a user decides to upgrade to a faster SCSI card (upgrades from a ISA card to a PCI card, for example), we do NOT want the setup to change. So we do NOT want to have the device number depend on the bus.
Or think of a portable: that's where you'd be a lot mroe likely to have the SCSI controller move around. Maybe somebody some day makes a PCMCIA SCSI card (or maybe they already exist?). Are you _really_ arguing for a setup where the disk numbers change depending on which PCMCIA slot the user has happened to use (or whether it's docked, perhaps).
Now, under _some_ circumstances it would help to have the bus position encoded in the number - for example if you add a new card and continue using the old card. However, this is not "normal operations" on PC's. People who do that kind of thing are people who can easily fix the setup anyway - they are most likely administering a server machine.
Now, I suggest we _also_ do a dynamic filesystem name mapping (so that you can have a fixed name even if you move a disk from one controller to another), but that would be a user-level issue and it's a "secondary" way to view the system (it simply cannot be the primary way, because it _cannot_ be made to work in all circumstances - two identical disks simply cannot be distinguished from each other in such a way that you could move them around and let the kernel notice).
I think I've shown how we can make the "normal operations" on PCs as simple as they are now. But how do we handle the complex cases?
Leonard
|  |