lkml.org 
[lkml]   [2002]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFT][PATCH] generic device DMA implementation

    >>- There's no analogue to pci_pool, and there's nothing like
    >> "kmalloc" (likely built from N dma-coherent pools).
    >
    >
    > I didn't want to build another memory pool re-implementation. The mempool API
    > seems to me to be flexible enough for this, is there some reason it won't work?

    I didn't notice any way it would track, and return, DMA addresses.
    It's much like a kmem_cache in that way.


    > I did consider wrappering mempool to make it easier, but I couldn't really
    > find a simplifying wrapper that wouldn't lose flexibility.

    In My Ideal World (tm) Linux would have some kind of memory allocator
    that'd be configured to use __get_free_pages() or dma_alloc_coherent()
    as appropriate. Fast, efficient; caching pre-initted objects; etc.

    I'm not sure how realistic that is. So long as APIs keep getting written
    so that drivers _must_ re-invent the "memory allocator" wheel, it's not.

    But ... if the generic DMA API includes such stuff, it'd be easy to replace
    a dumb implementation (have you seen pci_pool, or how usb_buffer_alloc
    works? :) with something more intelligent than any driver could justify
    writing for its own use.

    - Dave

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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