Actually, the bus_dma  stuff is a relatively small part of it. Justin has
said and I concur that the hardest actual issue might be what to do
about ATAPI (which is not addressed in FreeBSD/CAM).

There are a lot of neat instantly beneficial features (camcontrol as a
user level SCSI tool for one- as well as dynamic addition/rescan of
busses). It has real benefits. 

However, like all new projects, there's a lot of new code and I'm sure Ken
&& Justin would agree that some pieces could use a little of the 'aged in
oak' feel to them.

I've always maintained that of all the SCSI midlayers that have been
kicking around and coming and going for years that this implementation of
CAM shows the most promise of a smart I/O subsystem that can handle a
threaded environment- that doesn't mean it is a "done" thing (like
RaidFrame is a "done" thing)- it means that it is a base worth working
with as well as being as good as (if not substantially better) than the
current midlayer (well, and target drivers too). As with all such things,
there are plusses and minusses and tradeoffs involved- and I'm quite
content to let others make the call on this for NetBSD (I have been *soo*
much more serene since I started leaving most of my NetBSD related mail on
netbsd.org and only pick it up every few days or so...). At any rate, it
wouldn't be a trivial project, and should only be undertaken if there's a
pretty near unanimous consensus within the project that it should be done.

On Tue, 8 Dec 1998 seebs@plethora.net wrote:

> In message <Pine.LNX.4.04.9812072250070.28802-100000@feral-gw>, Matthew Jacob w
> rites:
> >I'll do the work if the consensus is to have CAM in NetBSD. But I won't
> >push for the decision.
> 
> My understanding is that it's hard because FreeBSD's implementation of
> bus_space is different from NetBSD's.  As I recall, this turns instantly
> into a "but this is unportable" "but this is inefficient" war, but it's
> still a technical barrier to importing CAM.
> 
> That said, from what I've heard it's a dramatically improved way of dealing
> with media, and I'd love to see it.  We could try to make 2.0 the "acronyms
> with M" release - CAM, SMP, UVM.
> 
> -s
>