Subject: Re: aix7xxx problems with negotiating "Ultra" speeds....
To: None <tls@rek.tjls.com>
From: Kenneth D. Merry <ken@plutotech.com>
List: current-users
Date: 12/09/1998 14:45:20
Thor Lancelot Simon wrote...
> On Wed, Dec 09, 1998 at 09:05:46PM +0100, Leo Weppelman wrote:
> > On Tue 08 Dec 1998, Matthew Jacob wrote:
> > >
> > >
> > > >
> > > > > I'll do the work if the consensus is to have CAM in NetBSD. But I won't
> > > > > push for the decision.
> > > >
> > > > The correct answer is "port is so it can be reasonably evaluated" :-)
> > > >
> > >
> > > No, evaluate as to whether the technology and implementation is desirable
> > > within NetBSD before someone goes to the substantial effort to get it into
> > > NetBSD, only to find it doesn't meet with vox populi approval.
> > >
> >
> > I think Matthew is right here. A major undertaking like this should be
> > backed by 'core'. I think that 'core' should state something like:
> > - if it performs at least as well as the current system
> > - if it works at least as well as the current system wrt. error
> > recovery, command handling etc.
>
> Let's add one here:
> - if it either coexists with the current system, or *all* host adapter
> and target drivers known to be in use (some are clearly "dead") with
> the current system are ported
That is a critical distinction to make. (That the drivers are "known to be
in use".) For the integration of CAM into FreeBSD, we made a conscious
decision that we would NOT have as many SCSI Adapter drivers as the old
SCSI layer did.
It wasn't because we didn't want to port everything, it's just that we
didn't have enough developer man hours and energy to do it. There were
some cards that didn't really have enough users to justify expending the
manpower porting the driver. We made the decision that it it was more
important to get the performance and reliability improvements that CAM
would bring, rather than expend the additional time to port every last HBA
driver that the old layer supported.
As far as peripheral drivers go, the FreeBSD CAM code supports every type
of peripheral that the old SCSI layer did, with one "exception". That
"exception" is the worm driver. The old FreeBSD worm driver only worked
with two types of non-standard WORM drives (HP 4020 and Plasmon), and thus
was useless for the new generation CD-RW's and CD-R's.
We decided instead to fully support cdrecord as the official cd burning
program. It supports far more drives than the old WORM driver did, and
even more drives than I plan on eventually supporting through the CAM CDROM
driver.
> > it will be accepted.
>
> There appears to be a substantial issue even in FreeBSD (which runs on a
> *lot* less hardware than we do) about "oddball" controllers not being
> supported with CAM. We may be somewhat better off here given the commonality
> of code we've striven to achieve between different platforms using the same
> host adapter chipset, but then again given the variety of platforms and SCSI
> host adapters we support -- we're probably a lot worse off.
Well, that's a decision that y'all (NetBSD) will have to make. Among the
other issues involved, you'll have to look at the current set of controller
drivers in CAM and compare it with the set of controller drivers in the
current NetBSD SCSI code.
If NetBSD does decide to go with CAM, I don't think you'll be able to get
away without porting some controller drivers to CAM. The primary reason is
the breadth of NetBSD's platform support, compared with FreeBSD's
relatively narrow platform focus. FreeBSD only supports i386 and Alpha,
and the available HBA drivers for CAM reflect that. NetBSD supports many
more platforms, and probably has a large number of other SCSI HBA drivers
that work on those platforms but not on i386.
Just for reference, here's the list of currently supported drivers in the
FreeBSD CAM code:
adv (Narrow Advansys cards)
adw (Wide Advansys cards)
aha (Adaptec 1542)
ahb (Adaptec 1742)
ahc (Adaptec 7xxx)
bt (BusLogic Multimaster)
dpt (DPT controllers)
isp (QLogic SCSI/FC controllers)
ncr (Symbios 810, 825, 875, etc. controllers)
Drivers that are either in progress, or we plan to port:
aic (Adaptec 6260/6360, Adaptec 1520, etc.)
uha (UltraStor 14F, 24F, 34F)
amd (AMD 53c974, Tekram DC390, maybe others)
bt (BusLogic Flashpoint support for the BusLogic driver. This was not in
the old SCSI layer)
Drivers that we do not plan on porting:
nca (NCR5380/NCR53400, PAS)
sea (Seagate ST01/02)
wds (WD7000)
??? (Future Domain 8xx/950)
Ken
--
Kenneth Merry
ken@plutotech.com