"Justin T. Gibbs" <gibbs@freefall.freebsd.org> writes:

> 
> I think we're missing each other here.  Forcing the device driver to do the
> copy from a bus_dma_segment_t into its own private format doesn't solve the
> structure alignment problem.

What `problem'?  Arguably, the device driver shouldn't be using a
structure at all, since structure packing isn't portable.  Tweaking
this one specific case misses the larger picture.

> In fact it forces each individual driver to
> handle it much the same as is done (or not done) now.

No; it removes all knowledge of how the addresses are mapped from the
device driver.  The point of this interface is to deal with mapping
arbitrary regions of memory into DMAable regions of memory.

> Having a family of
> functions that can be ported to different architectures and know how to
> deal with the SG formats completely removes the knowledge of how X arch
> aligns its data.

I don't see why this even makes *sense*.  The scatter/gather list
format is very much driver-specific.  Why do you think it belongs in a
device-neutral interface?

> I haven't been convinced that there is an architectural comprimize.  Right
> now I'm looking at more code, [...]

If you consider the general case of N architectures, M busses, and P
drivers:

* Jason's interface seems to require O(N*M) mapping functions plus
O(P) bits of code to convert the S/G list.

* An interface such as you suggest would require either O(N*M*P)
mapping functions, or O(N*M) mapping functions plus O(P) converters,
as above.  It's possible that a few of these converters may be
reusable, but most of them won't be.  It other worse, you either have
significantly more code, or you degenerate to more or less the same
thing as Jason's interface.

So just where do you get your claim of `more code'?

> architechtures.  Furthermore, the interface is not device, bus or
> machine dependant, it is simply SG format dependant.  The SG format
> dependencies have to be dealt with *somewhere*.  My point is only
> that by handling them in the interface itself, you gain efficiency
> and code reuse.

And you put knowledge of how a device works internally into what would
otherwise be a device-neutral interface.  That's architecturally
broken.  Worse, it means that any new device driver is likely to
require N*M pieces of additional code to be written and integrated,
making device driver development more difficult.

> With my proposal, the driver could only make assumtions about its
> own SG format and wouldn't even have to know how to build it.

I can't imagine why you think that's a win.  The format is
device-dependent.  Why should the device driver not know how to create
it?


All of the above said, it would be worth investigating the relative
performance penalty of using a callback, but this needs to be tested
on more architectures.


Since your only comments seem to be about performance, I'd suggest you
look at the Irix DMA mapping interface, and compare it with Jason's.
The Irix interface is more expensive, yet they seem to have achieved
.5GB/s I/O with it.

In short, I don't believe this is a real issue.