Subject: Re: On the subject of bus_dma(9)
To: None <firstname.lastname@example.org>
From: Ross Harvey <email@example.com>
Date: 03/07/2001 13:34:59
> From: Matthew Jacob <firstname.lastname@example.org>
> > 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.
> 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
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
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
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
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.
(*) 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?