[467] in linux-scsi channel archive

home help back first fref pref prev next nref lref last post

Re: Generic Scsi Driver Bug Report and comments.

daemon@ATHENA.MIT.EDU (Eric Youngdale)
Thu Aug 3 19:50:30 1995

From: "Eric Youngdale" <eric@aib.com>
Date: Thu, 3 Aug 1995 13:51:07 -0400
In-Reply-To: linux@pe1chl.ampr.org (Rob Janssen reading Linux mailinglist)
        "Re: Generic Scsi Driver Bug Report and comments." (Aug  2,  2:32pm)
To: linux-vger@wab-tis.rabobank.nl, Peter.Anvin@linux.org
Cc: submit-linux-dev-scsi@ratatosk.yggdrasil.com


>I think the suggestion of having only a single /dev/sg and then use
>an ioctl() to select the controller, id, and lun was more reasonable.
>It avoids /dev pollution and the limitations of an 8-bit minor number.
>
>Of course it does not address the problems with disks, tapes and cdroms.

	There is some discussion of a more permanant solution.  Instead of
hacking something for sg, I again suggest that we come up with something
that works for all scsi devices.

	One suggestion is to go to a larger dev_t.  This is not a trivial
change, and would result in lots of work to ensure backwards compatibility.
I am not even positive that a static mapping would fit in a 32 bit dev_t,
even if we used 14 bits for the major and 18 for the minor as is done under
SVr4.  Thus a 64 bit dev_t would probably be better (for some definition
of better).  I am a bit leery of this - I am concerned about performance
in device drivers as we manipulate device numbers, plus the usual bloat.
For machines with a 64 bit ALU, it is no big deal, of course, but not on the
i386.  The argument for a larger dev_t is driven not only by scsi - we could
use more room for ptys too, but for this a 32 bit dev_t would be sufficient.

	I have a secondary solution that I worked out about 6 months ago.
I cleaned it up and updated it a bit last night.  The program is called
scsidev, and it's purpose was to populate a /dev/scsi/ directory with
appropriate entries.  The idea is that you can run this
as part of the rc script after the root filestystem has been checked
and mounted R/W, and it changes/fixes things so that you will always
be able to refer to a given device by a name that specifies it's host
channel (if the driver supports multiple busses, or drives multiple cards),
ID, lun and partition.  Here is what it looks like on my system:

bash# ls -l /dev/scsi
total 0
crw-------   1 root     root       9, 128 Aug  3 13:20 rsth4c0i5l0
brw-------   1 root     root       8,   0 Aug  3 13:20 sdh4c0i0l0
brw-------   1 root     root       8,   1 Aug  3 13:20 sdh4c0i0l0p1
brw-------   1 root     root       8,   2 Aug  3 13:20 sdh4c0i0l0p2
brw-------   1 root     root       8,   3 Aug  3 13:20 sdh4c0i0l0p3
crw-------   1 root     root      21,   0 Aug  3 13:20 sgh4c0i0l0
crw-------   1 root     root      21,   1 Aug  3 13:20 sgh4c0i2l0
crw-------   1 root     root      21,   2 Aug  3 13:20 sgh4c0i5l0
br--------   1 root     root      11,   0 Aug  3 13:20 srh4c0i2l0
crw-------   1 root     root       9,   0 Aug  3 13:20 sth4c0i5l0

The program is smart enough that if it needs to change the major/minor
number for an entry, it attempts to stat an existing file to obtain the old
permissions and it then uses this for the new file.  It also saves file
ownerships, so that the only thing that effectively changes are
the major and minor numbers.

	It has a symlink mode where it generates entries in /dev/scsi
that are symlinks to the current /dev entries that is selected with the '-l'
switch, and you can specify a mode for all new device entries with the '-m
mode' switch.  There is also a '-f' switch which flushes everything from
/dev/scsi/ before generating entries.

	In the above the names consist of:

	h%d	- host number.  The 1542 driver is currently 4.  It is just
		  the inode number of the aha1542 directory in /proc/scsi
		  & 0xff.
	c%d	- channel (i.e. bus number).  If the card drives multiple
			  busses, or supports driving multiple cards, this
is how
		  we keep track of which one we want.
	i%d	- SCSI id.
	l%d	- SCSI lun.
	p%d	- Partition number (disks only).

My feeling is that the scsidev approach is more than sufficient to solve
the problems that people are having, and that a 64 bit dev_t is overkill.
I am tossing these ideas out so that other people can comment.

	The scsidev program can be found on tsx-11 in
pub/linux/ALPHA/scsi/scsidev.tar.gz

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

home help back first fref pref prev next nref lref last post