[lkml]   [1996]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: adding scsi devices

On Tue, 17 Dec 1996, Marty Leisner wrote:
> An echo `scsi singledevice 1 0 5 0' >
> /proc/scsi/scsi will cause host scsi1 to
> scan on SCSI channel 0 for a device on ID 5
> LUN 0. If there is already a device known on
> this address or the address is invalid an
> error will be returned.
> `
> I find this strategy awkward (to say the least) and I'm not sure what numbers
> to fill in (unless I write it down). I understand LUNs, is channel 0 the
> first scsi board (if we have only one board?).

Actually, "1" is the second SCSI controller ("0" would be the first), and
then "0" is the first SCSI "channel"/bus on that controller (some controllers
can have multiple SCSI bus hosts/controllers on the one "controller" or

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.


(this sig left intentionally blank - too many hats for one sig)

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