[478] in linux-scsi channel archive
Re: Generic Scsi Driver Bug Report and comments.
daemon@ATHENA.MIT.EDU (Craig "Woody"ward)
Fri Aug 4 20:34:23 1995
From: woody@mail.csh.rit.edu (Craig "Woody"ward)
Date: Fri, 4 Aug 1995 13:18:26 -0400
To: linux-scsi@vger.rutgers.edu
Cc: woody@mail.csh.rit.edu
"Eric Youngdale" <eric@aib.com> writes:
>
> 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.
> I have a secondary solution that I worked out about 6 months ago.
I agree with the point for making this for all SCSI systems, but
not with your solution. It's painfully obvious that we have to extend dev_t
to at least 32-bits, but thats about all anyone can agree on. I personally
don't like the 'auto dev creation' method you suggest because I don't like
the idea of something that low-level playing with a real FS. I also loath
setup scripts and /dev subdirectories.
Why not have the old /dev/s* devices work as 'generic lookups', and
put a new directory in /proc for named drivers? This lets drivers appear
and disappear on the fly, prevents changing a real FS, and will work even
on older-configured or CDROM-based systems. Then we can have something
like /proc/scsi/dev/aha154x that you can ioctl to your hearts content.
I think one major problem we have is that installing a new card
will (not so randomly) shift where drives are allocated at start-up. I can
see why you don't want that, but there are also reasons others may want that
dynamic changes, say for booting from a removable drive (ie Zip/Bernoulli).
Why not offer a bit in the new SCSI numbering system to indicate if the
device desired is dynamic or static? Then you can use the same numbering
system for dynamicly allocated files in /dev (or not) and the plug-n-play
files in /proc. This means that the number encoded in the kernel for root
FS mounting point can also be dynamic or static for those who want that
flexibility (or lack there of) at boot time!
>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 agree (tounge in cheek) that 64bit seems a bit excessive, but I
think the best place to put such dynamic, kernel-internal things is in the
/proc file system. I also feel that having different entries for each
device feature would be wonderful, but could easily be compensated for
by ioctls. I think the best solution would be:
Bit Meaning
31 set for static, clear for dynamic
30-16 [static] 16384 unique IDs [dynamic] unused?
16-10 [all] Max # of IDs [dynamic] unused?
9-3 [static] lun (0-63) [dynamic] drive/dev number
2-0 [disk] slice-id [other] channel id/whatever?
The rest of the functionality you want you get the same way you do now, with
ioctls. All the devs in /proc would have the high-bit set, the ones in /dev
and in the kernel (for root FS id) could have either depending on the admin.
Comments, ideas, job offers? :)
-Woody
