John,

you seem to have jumped into this halfway through.  Many of the
responses so far have, regrettably, not focused on the technical
issues of the bus-dma interface.  Please dont' start more.

Some of us are trying, hard, to understand the other side's position.
I at least am still hoping we can resolve the differences in this API.
Some of Justin's ideas are good, I've said so, and (unless they cause
unforseen problems) I'd like NetBSD to buy them back.  I can and do
appreciate the urge to respond in kind, but I genuinely dont think
comments like your post help with better communicating on the
technical issues here.

> We certainly don't want to be constrained
>by the limitations of an OS that has lots of ports...  sort of...

(sort of?)
You seem to be missing the fact that Justin claimed:

  }[..]  the NetBSD interface
  }sacrifices speed and memory resources for absolutely no gain in
  }portability.

Please don't jump in and say we are not arguing about portability,
because we clearly *are*. Some very smart people are still not clear
what the technical merits of the relevant positions are.

Stirring up flames with insinuations that NetBSD gains "quantity" at
the sake of "quality" is only going to offend.


>This is a quality vs. quantity argument.  I suggest that there
>is a difference between "working" and "WORKING."

Yes.  Obviously, One is upper case, the other is lower.  I don't
understand the distinction you are making.  I doubt anyone else (from
NetBSD) does either. Which is better, and is the metric of goodness
raw, peak-downhill-tailwind speed on one specific architcture; or
correctness on a very large number of disparate architectures?  Or is
it reliable, maintainable code?  Or clean architectural design that
allows for portability?  or some mix of all of the above?
We could argue all day.

(NB: I sincerely dont see that this adds to this particular technical
discussion, so I dont have time to follow up an answer today.)



> I am very
>concerned about some peoples generalization of NetBSD behavior
>to FreeBSD.

Again I think you have the facts of the technical claims made here
completely backward.  Justin said that (I quote)

  }[..]  the NetBSD interface
  }sacrifices speed and memory resources for absolutely no gain in
  }portability.

and that claimw as, AFAIK,  based solely on experience with FreeBSD.