"Let me make myself perfectly clear"- *if* there's a consensus that the
CAM architecture is the way to go and NetBSD commits to adopt this, then
I'll try and bust loose the time to do the work- as due diligence as an
employee of NASA/Ames as well as a NetBSD developer (whose commitment to
NetBSD has shrunk substantially over the last year- to be honest).

However, I am unwilling to break loose this time and move myself off of
other projects that really cry for the work to be done without some
assurance that this would be desired and adopted by NetBSD. I'm also a
FreeBSD developer, and I can continue to improve the CAM subsystem there
too. My notion that it might be beneficial to NetBSD is also driven by the
notion that NetBSD and FreeBSD should share much more code than they
currently do (it save *me* time from having to maintain, say, two
different versions of the Qlogic ISP driver).

I realize that this sounds like a "pig in a poke" kind of answer- but it
is a substantial amount of effort to do this. That's why I said earlier in
this thread (paraphrasing), "I'd be glad to help on this and am willing to
do the work, but I won't push for it.".

I think there are 3 scenarios here:

1	If the general consensus of NetBSD core is that this should be
	the way to go (import CAM into NetBSD), then people will commit
	the time to make it happen.

2	If the general consensus of NetBSD core is "do the work first and
	then we'll see", it probably won't happen.

3	If the general consensus of NetBSD core is "We think this is a
	good idea, but in the process of importing this into NetBSD make
	sure that the code quality and design improves so it meets *our*
	standards", it *might* happen.

The only opinion from NetBSD core I've heard is from Jason (I believe- and
he's a core member until today I guess)- and that opinion was #2. I
believe that #3 is the best compromise scenario- I'm all for very high
standards of design and quality, but since software is such an inherently
improvisational art form, there's often a notion of buying into designs
that are moving targets.

Perhaps someone who has more time available than I do should undertake
the work? If that's the case, then the beneficial thing would be to make
sure that there's a feedback loop into FreeBSD so that both projects
benefit.

-matt


On Thu, 10 Dec 1998, David Carrel wrote:

> OK, allow me to make a suggestion here.  I would like to see the FreeBSD
> CAM code ported to NetBSD.  I think an appropriate way to do this is to
> make it available via ftp on ftp.netbsd.org while it develops.  Many pieces
> of code go this route.  If they evolve to a point where NetBSD want's it in
> the main sources, then great!  If not, hopefully some other code will come
> along.  But by having this code ported to NetBSD, we can learn what we like
> and what we don't like about it.
> 
> Matt, you have expressed interest in doing this work.  Please do.  Other's
> have expressed interest in working on it too.  If a branch in the CVS
> repository helps do joint development, then please use that.
> 
> At a minimum it seems the code must be ported to work with NetBSD's bus_dma
> as is.  It must also allow one to build a kernel with either CAM or the
> current SCSI.  There are many other goals people have mentioned on this
> list.  Such things as simultaneous co-existance with the current SCSI,
> ATAPI and much more.  These are things to look into once an initial port is
> done.  I'm sure many more suggestions will come along.  Hopefully dialog
> will continue and all suggestions will be considered.
> 
> No one can/will promise that this code will make it into the main code
> base.  But this is definitely a good path.  Either the code will make it
> in, or we will learn from it.  I think the PCMCIA code is a great example.
> There was code available for ftp for a long time.  It was useful, and I
> think people learned from it.  Eventually it was scrapped for a complete
> re-write, but that doesn't mean the old code wasn't very valuable.
> 
> Thanks for listening!
> 
> Dave
>