Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]

[David Brownell <david-b@pacbell.net>]

>  > Given that some hardware must return the dma addresses, why
>  > should it be a good thing to have an API that doesn't expose
>  > the notion of a reverse mapping?  At this level -- not the lower
>  > level code touching hardware PTEs.
> 
> Because its' _very_ expensive on certain machines.  You have to do
> 1 or more I/O accesses to get at the PTEs.

Except, I said this was NOT at that level.  Those costs don't
need to be incurred, but you are reasoning as if they did.


> If you add this reverse notion to just one API (the dma pool one) then
> people will complain (rightly) that there is not orthogonality in the
> API since the other mapping functions do not provide it.

"Orthogonality" is the wrong word there.  In fact, this is a highly
orthogonal approach:  each layer deals with distinct problems.
(Which is why I'd ignore that complaint.)

There's a bunch of functionality drivers need to have, and which
the pci_*_consistent() layer APIs (rightly) don't provide.  Just
like a kmem_cache provides functionality that's not visible
through the generic page allocator code; except that this needs
to work with the pci-specific page allocator.

It feels to me like you're being inconsistent here, objecting
to a library API for some functionality (mapping) yet not for
any of the other functionality (alignment, small size, poisoning
and so on).  And yet when Pete Zaitcev described what that
mapping code actually involved, you didn't object.  So you've
succeeded in confusing me.  Care to unconfuse?

- Dave