[3331] in linux-scsi channel archive
Re: SCSI host numbering (patch)
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Sat Feb 14 18:53:12 1998
Date: Sat, 14 Feb 1998 19:13:13 -0500 (EST)
From: Eric Youngdale <eric@andante.jic.com>
To: Dario_Ballabio <Dario_Ballabio@milano.europe.dg.com>
cc: linux-scsi@vger.rutgers.edu, ankry@green.mif.pg.gda.pl
In-Reply-To: <199802141614.RAA21128@milano.europe.dg.com>
On Sat, 14 Feb 1998, Dario_Ballabio wrote:
> I'm in favour of a fixed mapping which statically allocates
> host numbers in a predictable way and determines the loading order
> as well.
> For example "scsi_hosts=eata:4,ncr:2,buslogic:3,aic:0,none:2,eata:2"
> would cause:
> eata beeing loaded first and assigned scsi0 to scsi3;
> ncr beeing loaded second and assigned scsi4 to scsi5;
> buslogic beeing loaded third and assigned scsi6 to scsi8;
> aic beeing skipped even if compiled into the kernel;
> scsi9 to scsi10 beeing reserved;
> eata beeing loaded (as a module) and assigned scsi11 to scsi12.
>
> This would address the long standing problem of probe order,
> provides the required flessibility and seems rather simple
> to implement.
Is the goal to control probe order, or is the goal to control
device naming? In other words, if the problem isn't strictly probe
order, then it isn't stricly a requirement that the actual probe order be
controlled - itn't it simply the host *numbering* that we want to control.
Secondly, just controlling the host numbering doesn't affect how
the host numbers allocated to a given controller are actually allocated to
the individual cards and/or busses that might be present. It wasn't even
designed for this purpose, really. Initially the point of the host number
was just so that you could display a nice "scsi0", "scsi1", etc at boot up
time, and correlate the devices that are detected with the hosts that are
detected. This leaves us in the situation that we are depending upon and
trying to fix something to do something which it wasn't designed for in
the first place.
It was in order to provide a 100% reliable mapping that I added
the unique_id field to the host structure - for the 1542, this is simply
the I/O address, but it could be anything that is guaranteed to be unique
and will be independent of the presence or absence of any other hardware.
Most drivers don't bother to set this field, unfortunately.
That's all history, however.. The above suggestion does lead me to
an interesting idea, however. Instead of controlling how host numbers are
allocated (or perhaps in addition to), we can effectively control the
device mapping in the following way:
The scsi code could maintain an aliasing scheme, whereby either
through kernel command parameters, or through commands sent through
/proc/scsi/scsi, the kernel would effectively maintain a secondary
mapping from minor number to device.
Let me elaborate - you could use a kernel parameter something
like:
scsi_dev_mapping="1=aha1542,$host,$id,$lun"
Would map the device with the specified parameters to an identifier "1".
How do we make use of this?
Let's say for the sake of argument that we have a dev_t
that is 32 bits, with 16 bit major and a 16 bit minor.
Then let's say that we have
(IDENTIFIER_OFFSET << IDENTIFIER_SHIFT) == 16384
then you could use:
ID=1
echo "map $ID=aha1542,0,0,5,0" > /proc/scsi/scsi
mknod /dev/diskid1 b 8 `expr 16384 + $ID \* 16`
mknod /dev/diskid1p1 b 8 `expr 16384 + $ID \* 16 + 1`
mount /dev/diskid1 /mnt/foo
The point is that the mapping table is empty until you add things to it -
in effect it is fully dynamic, but again you fully control what gets added
where. It would only be minor numbers >= 16384 that are looked up in the
mapping table - minors below this value would be used as they are now.
-Eric
