lkml.org 
[lkml]   [2006]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 08/19] dmaengine: enable multiple clients and operations
    Dan Williams wrote:
    > On 9/11/06, Roland Dreier <rdreier@cisco.com> wrote:
    >> Jeff> Are we really going to add a set of hooks for each DMA
    >> Jeff> engine whizbang feature?
    > ...ok, but at some level we are going to need a file that has:
    > EXPORT_SYMBOL_GPL(dma_whizbang_op1)
    > . . .
    > EXPORT_SYMBOL_GPL(dma_whizbang_opX)
    > correct?

    If properly modularized, you'll have multiple files with such exports.

    Or perhaps you won't have such exports at all, if it is hidden inside a
    module-specific struct-of-hooks.


    > I understand what you are saying Jeff, the implementation can be made
    > better, but something I think is valuable is the ability to write
    > clients once like NET_DMA and RAID5_DMA and have them run without
    > modification on any platform that can provide the engine interface
    > rather than needing a client per architecture
    > IOP_RAID5_DMA...FOO_X_RAID5_DMA.

    It depends on the situation.

    The hardware capabilities exported by each platform[or device] vary
    greatly, not only in the raw capabilities provided, but also in the
    level of offload.

    In general, we don't want to see hardware-specific stuff in generic
    code, though...


    > Or is this an example of the where "Do What You Must, And No More"
    > comes in, i.e. don't worry about making a generic RAID5_DMA while
    > there is only one implementation existence?

    > I also want to pose the question of whether the dmaengine interface
    > should handle cryptographic transforms? We already have Acrypto:
    > http://tservice.net.ru/~s0mbre/blog/devel/acrypto/index.html. At the
    > same time since IOPs can do Galois Field multiplication and XOR it
    > would be nice to take advantage of that for crypto acceleration, but
    > this does not fit the model of a device that Acrypto supports.

    It would be quite interesting to see where the synergies are between the
    two, at the very least. "async [transform|sum]" is a superset of "async
    crypto" after all.

    Jeff


    -
    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: 2006-09-13 06:07    [W:2.927 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site