[53] in linux-scsi channel archive
Re: Probing luns > 0
daemon@ATHENA.MIT.EDU (Fons Botman)
Tue Jan 31 08:09:44 1995
To: linux-scsi@vger.rutgers.edu
Date: Tue, 31 Jan 95 11:57:45 MET
From: Fons Botman <ND3995!botman@relay.nl.net>
In-Reply-To: <9501250923.AA13328@eng.kvaerner.no>; from "Andrew Walker" at Jan 25, 95 10:23 am
Reply-To: botman@rabo.nl
> > > Drew Eckhardt <drew@boulder.openware.com> wrote:
> > > > There are still large numbers of broken SCSI devices out there which
> > > > are extremely unhappy (ie, lock the SCSI bus up, do an unexpected
> > > > disconnect, etc) when you attempt to talk to them at a LUN other
> > > > than 0.
> > > >
> > > > Comments?
>
> One suggestion is a command line like:
>
> max_scsi_luns=07007070
>
> Now we just have to find out what's most acceptable to most of the people.
> Just being a wet blanket as usual :-(
As usual the solution could be "all of the above".
If I compile at home, a lilo option is the simplest solution and a smaller
kernel is an advantage. At work, I run linux on several different machines
(some without lilo), a "safer" kernel with black and/or whitelists which
can run on many machines without options is better or at least more managable.
Also kernels for distributions benefit from builtin knowledge.
Having both white and blacklist is an advantage i think, you can
recognize the "unknown and potetially dangerous" case.
If the code for white/blacklists is allready there please leave it there
and use a configuration time "ifdef" to enable it by default.
The lilo options is a must in any case, to solve configuration problems.
The same arguments are valid for (most) other parts of the kernel, I think.
The Fons.
