I've largely tried to stay out of this, only answering direct
questions where asked or amplifying or clarifying points where I
thought it appropriate.  This departs from that somewhat.  8-)

> > HOWEVER, my point still stands. I believe claims of improved
> > performance when I see reproduceable benchmarks. I believe claims of
> > portability when I see a port. I *know* that NetBSD's code ports well, 
> > because we spent years beating on it until it would. FreeBSD hasn't
> > finished one port from its original architecture. I would like to see
> > justification for claims of performance and portability -- not
> > theoreticals.
> > 
> Does that mean that the FreeBSD development should move forward,
> and then when we  have reproduceable benchmarks on FreeBSD, then
> you can choose to adopt our code, or leave it be?

*sigh*  With respect to the interface in question, I _HOPE_ you
understand that that suggestion is pretty much useless.

If the goal is to figure out how to evolve the bus_dma interface, the
what you really need is to compare the performance and portability of
the interface with and without the changes that have been proposed.

Benchmarking the system with countless other changes _does not help_,
and you, as a software engineer, should know that.  Change one
variable at a time.

I think the whole point here is that NetBSD has the bus_dma interface
deployed in a large number of architectures and drivers, and a change
has been proposed.  Along with that change, there have been no
_concrete_ examples that it has any significant, or even _measurable_
effect on system performance.  If you propose a change that you want
people to do a lot of work to implement, it's only right that you give
them proof that it works as advertised, e.g. in the form of "before"
and "after" tests where it is the only thing changed.  As far as I can
tell (and I'll admit that I've not been watching closely), that's
never been done, even for the i386 case.  (In my opinion, given that
one of the goals of the interface is portability, it's wrong to do
such tests only on the i386, but I don't think I've seen _any_ data.)
I'm not doubting your credibility or stature as software engineers, I
just want to see a solid demonstration that the changes proposed solve
a problem.  As much data (for different controllers, architectures,
etc.) as possible should be provided, so that the whole picture is
clear.


In a nutshell, if you can demonstrate that the interface changes
quantifiably improve performance on at least one, but preferably more,
architectures without sacrificing portability (or performance on the
other architectures), then they are worth implementing, or at least
investigating further.  Providing solid information like that at least
puts the onus on the people who want to keep the interface as it is now.

If you cannot, or not willing to, then, to be quite frank, you
shouldn't have gotten behind them in the first place, and you should
revert your interface to match the NetBSD one.  Making changes without
solid justification (like that which i've outlined above) is simply
bad engineering practice.  (I don't think I have to tell you that;
it's a non sequitur.)




cgd