[745] in linux-scsi channel archive
Re: Boot Kernels
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Thu Nov 2 02:11:02 1995
Date: Wed, 1 Nov 1995 10:19:58 -0800
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: eric@aib.com
Cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <9511010913.ZM11262@aib.com> (eric@aib.com)
From: "Eric Youngdale" <eric@aib.com>
Date: Wed, 1 Nov 1995 09:13:09 -0500
The approach that had been informally discussed earlier is to
use the /proc/scsi/ interface to turn on/off features like tagged queueing
and some of these other features. The idea is that the driver would come
up with many of these things turned off, and the sysmgr could enable them
if they appear to work reliably. The procedure would be to write some kind
of ascii string to the device like:
echo "tagged_queue=enable" > /proc/scsi/aha1542/0
which would be meaningless in this case, since the 1542 does not support
tagged queueing, but you get the idea. This is something that could easily
be integrated into rc scripts.
I'll have to look into the myriad possibilities of /proc/scsi when I start
adding 1.3-specific options.
Will it be possible to install and remove devices at some point as well? I
move a DDS DAT drive around between machines and it would be great not to have
to reboot every time.
Another solution would be one boot option like "wussy-scsi" that
disables some of the things like tagged queueing and so forth to increase
the chances of a successful boot. The idea is that there would be only one
such switch that could be tested by all of the low-level drivers.
This is a non-problem if command line options are available, since I *already*
support per-target control of tagged queuing. The case I was concerned about
was floppy booting for installation, and it seems I was way out of date on my
understanding of how current Slackware style installation works. The last
Slackware I actually installed directly was 1.2 well over a year ago.
I've only found *one* situation where tagged queuing has been a problem once I
had the correct information about which BusLogic firmware versions support it
correctly, so I don't think this will come up very often in practice. Now that
I see that there is a way to handle it diring installation if necessary, I'm
not concerned.
Leonard
