> 
> > However, Eduardo and I have been raising what we consider a narrowness of
> > scope of the current architecture too. It seems to us that it'd be better to
> > give a hint earlier. Clearly some people think that this spec is perfect and
> > shouldn't change. Saying that the sparc64 is wacky or just buggy is not either
> > correct or accurate when we're raising legitimate questions about the
> > architecture.
> 
> This paragraph quickly accuses me or "some people" of having no judgment,

Not intentionally, I assure you! 

> calling sparc64 wacky and buggy, and accuses people of rejecting a valuable
> feature for no good reason. Every piece of that is false and should not have
> been said.  I shouldn't have to spell all this out, but at least I type
> quickly...


> 

>   o  Few things are perfect. Since engineering is one compromise after
>      another, it isn't a good practice to throw in features just because
>      a hypothetical use for them has been tossed out. We really need a
>      clear and, err, "coherent" (:-) argument that specifies the sparc64
>      features that are being obliquely referred to.  Then, people can see
>      whether or not sparc64 can reasonably fit into bus_dma(9). It's only
>      if the answer to THAT is "no" that its time to discuss new features!
> 
>      By going back and forth between vague references to non-bus-dma-able
>      HW and then agreeing that sparc64 CAN fit into bus_dma(9) but then
>      again bringing up the new feature anyway you aren't even making a
>      clear statement and it's driving at least me slightly crazy trying to
>      follow it.
> 
>      Simply mentioning a proposed new feature is easy, but that's not
>      sufficient reason to just inject it into bus_dma(9) at this late
>      date, not after it has proved itself over and over.(*) Do you want
>      to go back and change all the conforming implementations for a
>      feature that was never needed? If you allow different specifications
>      drivers down the line _will_ use them.
> 
>      Jason said exactly that, but used only two sentences. The above is
>      the best I can do.


Not on  point, I believe.  You used the term 'wacky' and jason called sparc64
'buggy'. Neither were appropriate terms under the circumstances.


>   o  If you are going to diverge from the technical issues by implying that
>      "some people" are lacking in judgment, that is, stating that people
>      have a preconceived notion that bus_dma(9) is perfect, others could
>      start questioning yours and speculate on the reasons you are looking
>      so hard for a bug or shortcoming in bus_dma(9).  It would seem best
>      to keep the discussion technical, if there is in fact even anything
>      to discuss.

The above paragraph's advice has been taken and thus the paragraph has been
ignored.

> 
>   o  Sigh, I _never_ called sparc64 `wacky' or `buggy', or even implied
>      either.

'Could hae sworn I saw it in your mail. No matter.

> I'll say it again using more words: Even things that really
>      are wacky seem to fit nicely into bus_dma(9). My implication was that
>      if sparc64 is NOT wacky then it should be an even easier fit.  Jason
>      did mention bugs in the interface usage; I don't see what was wrong
>      with saying that.


Let's move to closure on this in the technical space. 

> 
> 	 -- Ross
> 
>  (*) Incidentally, it's possible that there may never again be an OS that
>  is ported as widely or to such disparate platforms as NetBSD. There were
>  a _lot_ more automobile companies (and auto designs) in the early 1900's
>  than there are now in the early 2000's. What if a similar convergence
>  happens in CPU's?

Has already.