[474] in linux-scsi channel archive
Re: Generic Scsi Driver Bug Report and comments.
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Fri Aug 4 03:59:24 1995
From: "Eric Youngdale" <eric@aib.com>
Date: Thu, 3 Aug 1995 18:34:59 -0400
In-Reply-To: hpa@asgard.yggdrasil.com (H. Peter Anvin)
"Re: Generic Scsi Driver Bug Report and comments." (Aug 3, 5:46am)
To: Peter.Anvin@linux.org (H. Peter Anvin),
submit-linux-dev-scsi@ratatosk.yggdrasil.com
>AFAIK, the constraints to keep in mind are:
>
> # of LUNs/ID 3 bits (can this be more on
wide/xwideSCSI?)
> Max # of IDs 5 bits (Extra wide SCSI = 32 IDs)>
> Controllers 3-4 bits
> Partitions 4-6 bits
> --------------
> 15-18 bits
>
>Hence, going to 32 bits (16+16) *should* be enough, but there is
>certainly a case worth arguing for going all the way to 64 bits. I
>*presume* noone's interested in a nonsymmetric solution (e.g. 12+20).
Most of the above looks OK to me. Part of the problem is that we
would like to be able to identify which controller/which bus on on the
controller in a unique way. We currently have about 20 drivers, and I
would not want to limit myself by only assigning 5 bits for the host adapter
type - therefore I would say 6 bits for this. I would also suggest
3 bits for the channel number (so you could have up to 8 independent busses
being driven by each driver). With something like this, you really do run
short of bits, even with a 14/18 like SVr4 uses (or even 12/20).
Anyways, the above math is what led me to think of the scsidev
program that I described in a previous email. I would still argue that a
32 bit dev_t is useful for other reasons, but my gut feeling is that this
is not the solution for us.
-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."
