[lkml]   [2001]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]
>  > 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:29    [W:0.129 / U:2.024 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site