Jason Thorpe wrote...
> On Wed, 09 Dec 1998 16:15:59 -0700 
>  "Justin T. Gibbs" <gibbs@plutotech.com> wrote:
> 
>  > >I agree, and there ARE a lot of problems with the CAM code.
>  > 
>  > Lots == 2?  Seems like a glowing recommendation!
> 
> Did I say those were the only ones?
> 
> 	(3) No support for ATAPI (show-stopper).

That can be fixed if someone wants to work on it.  Manuel Bouyer indicated
he would help with that.

> 	(4) Some missing target drivers (show-stopper).

Target drivers??  There's only one target-mode driver, and it's a
target-mode processor target driver.  What missing target drivers are you
talking about?

> 	(5) Serious lack of documentation (show-stopper, because without
> 	    this, how do we make the plethora of HBA drivers we support
> 	    work?)

And how much documentation do you have on the current NetBSD SCSI layer?

Matt Jacob (isp) and Warner Losh (aha) have ported HBA drivers to CAM with
only other drivers for documentation and Justin's assistance.  So it is
possible to do.

There are the CAM specs, of course, which provide you with an idea of how
things are supposed to work.  And there are plenty of example drivers.

> 	(6) There seems to be this notion of "physical addresses" within
> 	    the CAM code itself.  What's going on here?  This isn't
> 	    exactly portable.

I think they're actually bus addresses, but "physical addresses" is the
term the CAM spec uses, therefore that's the term we used.

As for what's going on, it allows the creator of a CCB to pass in a
non-virtual address of a piece of memory that will be used to transmit or
receive data.  For instance, I've used it with chunks of "physical" memory
to get around physio's limits on the amount of data you can transfer from
userland programs.  (Pass a CCB through the pass(4) driver with a physical
memory pointer to a region somewhere in memory.  The pass(4) driver won't
try to map it into kernel virtual address space since it isn't a userland
virtual address.  The controller driver has to support the CAM_DATA_PHYS
CCB flag, though.)

> 	(7) Host bus adapter drivers misuse bus_dma, almost as a feature.

Justin can comment on that...

> Anyhow, those are a few more based on my very quick glance at FreeBSD-current.

If you do decide to integrate CAM into NetBSD, you will have to expend some
amount of effort to make it happen.  It won't come for free.

If having integrated ATAPI support is a requirement, someone will have to
do the work.  Either that'll happen in FreeBSD, or someone in NetBSD will
have to do it.

If controller drivers are the bottleneck, folks will have to step up to the
plate and port things.  It's unlikely that many of the HBAs that NetBSD
supports will ever be supported by FreeBSD, since they aren't used on either
of the platforms that FreeBSD supports.

In the end, NetBSD will have to weigh the merits of integrating CAM against
the drawbacks, and make a judgement on whether to go with it.  Or, you don't
have to even consider doing it, and just stick with the current SCSI layer.

CAM seems to be working well so far for FreeBSD.  NetBSD necessarily has a
different set of requirements, and so what may be "good" for FreeBSD may
not be "good" for NetBSD.  It's something you'll have to decide for
yourselves.  Justin and I will be glad to answer questions about it,
though.  More information may make it more clear whether it would be
beneficial or not.


Ken
-- 
Kenneth Merry
ken@plutotech.com