[472] in linux-scsi channel archive
Re: Generic Scsi Driver Bug Report and comments.
daemon@ATHENA.MIT.EDU (Drew Eckhardt)
Fri Aug 4 00:43:37 1995
To: Peter.Anvin@linux.org (H. Peter Anvin)
cc: submit-linux-dev-scsi@ratatosk.yggdrasil.com, linux-scsi@vger.rutgers.edu
In-reply-to: Your message of "03 Aug 1995 05:46:19 GMT."
<hpa.30206117.Allah.u.Abha@asgard.yggdrasil.com>
Date: Thu, 03 Aug 1995 13:53:42 -0600
From: Drew Eckhardt <drew@poohsticks.org>
In message <hpa.30206117.Allah.u.Abha@asgard.yggdrasil.com>, hpa@asgard.yggdras
il.com writes:
>Followup to: <9508021612.ZM26895@aib.com>
>By author: "Eric Youngdale" <eric@aib.com>
>In newsgroup: linux.dev.scsi
>>
>> I think the point is being missed here. The issue is not so much
>> the namespace that is used, but how to map minor numbers to real devices.
>> While it would be nice to be able to fix this just for the sg driver,
>> I would prefer a more generic solution that works for all scsi devices
>> (disks, cdroms, etc), since the same problems occur there too.
>>
>
>This is true. This would require going to a 32- or 64-bit dev_t,
>however. libc-5 has the necessary hooks for changing the size of
>dev_t (it includes a version number in its stat call), and with the
>1.3 development kernel in full swing it is about the right time to
>make such a migration.
>
>AFAIK, the constraints to keep in mind are:
>
> # of LUNs/ID 3 bits (can this be more on wide/xwide SCSI?)
No, but SCSI-III extends the LUN to 5 bits.
> Max # of IDs 5 bits (Extra wide SCSI = 32 IDs)
Nope. 7 bits - SSA allows for 128 addresses.
> Controllers 3-4 bits
Nope. The biggest reason we want the new device numbering scheme is
so that devices don't "move" when some one plugs in a new device /
controller/whatever.
Plug in a sound board with SCSI that relocates your existing
SCSI controller or vice versa, and your assignments change. Not
good.
You want to uniquely identify each SCSI host by something that
doesn't move. This is going to be driver number (we have 20+ SCSI
drivers now, double a couple times and 7-8 bits makes us more comfortable)
plus some unique
identifier, which would be at least
EISA slot number smaller
PCI bus, device, and function 16
ISA/VESA I/O mapped 10
ISA/VESA memory mapped (will be < 1M, will 16
be 16 byte aligned for historic
reasons on ISA machines)
We also need to consider what the case will be for the busses on
non-PC bus architectures, and each driver might support multiple
mapping methods, so you want 3 bits for that.
Ie, we want 48 bits for minor so far.
> Partitions 4-6 bits
> --------------
> 15-18 bits
Call it 54. Use the remaining 10 bits for major.
>Hence, going to 32 bits (16+16) *should* be enough
32 is definately not; 64 is but just barely and only if we go for asymetry.
>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).
So you'd prefer a 128 bit dev_t :-)
