> From: Matthew Jacob <mjacob@feral.com>
...
:::
> > For that matter, if the platform is totally wacky it can just make a thunk
> > and postpone the allocation, or it can later free it and reallocate things
> > if it gets a more difficult and unusual coherent case. The sync calls are
> > still needed for the proper interface, even if they need not do anything
> > for a specific mapping.
> > 
> > I've seen more unusual things than sparc64 fit into the bus_dma(9) framework
> > as it stands right now, and I bet sparc64 could too if properly implemented.
>
> I don't believe that sparc64 and an IOMMU that has streaming or byte-coherent
> mode is all that 'wacky'. The same issues occur in sparc- but there is an
> *implicit* allocation of byte coherent memory (for both the device and the
> CPU) in NetBSD/sparc.

I did not apply `wacky' to the sparc64 or to the IOMMU.

> In theory you *could* do the alloc/realloc if you really wanted to get
> aggressive with opaque handles. That's also a fine implementation strategy.

Thank you.

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

  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.

  o  Sigh, I _never_ called sparc64 `wacky' or `buggy', or even implied
     either. 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.

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