[1126] in linux-scsi channel archive
Re: adding scsi devices
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Thu Dec 19 03:40:06 1996
Date: Wed, 18 Dec 1996 13:57:52 -0500
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Andy Poling <andy@realbig.com>
Cc: Marty Leisner <leisner@sdsp.mc.xerox.com>, linux-kernel@vger.rutgers.edu,
linux-scsi@vger.rutgers.edu
In-Reply-To: Andy Poling's message of Tue, 17 Dec 1996 21:17:53 -0500 (EST),
<Pine.LNX.3.91.961217205832.32374E-100000@ws.realbig.com>
Date: Tue, 17 Dec 1996 21:17:53 -0500 (EST)
From: Andy Poling <andy@realbig.com>
That part makes sense. What doesn't make sense is that you don't know what
device name it will have. I mean, you will if you (you being software at
this point) somehow magically know the controller, bus, ID and LUN of every
other device on the system, but that doesn't make good sense.
The whole Linux scheme for naming devices on SCSI (and IDE) busses is
awkward - period. If I add a disk as SCSI ID 0 then, guess what? All of
the sudden none of my SCSI disks have the same device names as before
(despite the fact that none of their SCSI ID's have changed). Wonderful -
that's not confusing at all...
I'm sure the originator of this scheme had a good reason, but so far it
escapes me. My best guess is that it was a misguided decision to continue
DOS's braindead convention of calling the first disk found disk1, the second
2, etc. Yech - surely Linux is better than DOS. Every other UN*X-like OS I
have experience with names devices by their actual controller, bus, ID, and
LUN. That's predictable.
The real problem is that there isn't enough space in the 8-bit minor
device number space to address the controller, bus, ID, and LUN bits.
When we move to using a 32-bit minor device number, it will make a
scheme like this much easier to do under Linux.
- Ted
