[3335] in linux-scsi channel archive
Re: SCSI host numbering (patch)
daemon@ATHENA.MIT.EDU (Andrzej Krzysztofowicz)
Sun Feb 15 06:26:48 1998
From: Andrzej Krzysztofowicz <ankry@green.mif.pg.gda.pl>
To: eric@andante.jic.com (Eric Youngdale)
Date: Sun, 15 Feb 1998 12:24:17 +0100 (CET)
Cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.95.980214181414.3033C-100000@andante.jic.com> from "Eric Youngdale" at Feb 14, 98 07:13:13 pm
> 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.
Stable host numbers (notice: it's not the same as probing order) will not
solve the device naming (problem of probe order) in standard kernels.
Also, defined probe order is useless if you use modules.
But stable host numbers (not: probe order) are necessary if you use
devfs + scsi modules.
> Is the goal to control probe order, or is the goal to control
If you use devfs - it is.
> 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
You can control the probing sequence by the host adapter driver parameter
(of course if driver support this)
> 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.
If you use devfs the device names have form c#b#t#l# and definitely depend
on the host number (c#). Introducing the devfs is a way to omit the old
problem that device names depend on autodetection sequence. But to be fully
functional it needs a stable host numbering system.
> 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
It can be useful. I didn't notice that. Thanks
> 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"
I think there's no reason to solve the same problem parallelly in two ways -
devfs and its naming scheme solve device numbering problem (among a few
others)
>
> 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
>
>
Regards
--
=======================================================================
Andrzej M. Krzysztofowicz ankry@mif.pg.gda.pl
phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math., Technical University of Gdansk
