>
> > 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.