lkml.org 
[lkml]   [1996]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.067 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site