lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikD2LwYwsk6Q-7U-P3o+ujhY_0TqgeqOo=hhjA=@mail.gmail.com>
Date:	Wed, 11 Aug 2010 21:02:04 +0200
From:	Linus Walleij <linus.ml.walleij@...il.com>
To:	Rabin Vincent <rabin@....in>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org, Sascha Hauer <s.hauer@...gutronix.de>
Subject: Re: [PATCH] DMAENGINE: add a slave buffer prep call

2010/8/11 Rabin Vincent <rabin@....in>:

> On Tue, Aug 10, 2010 at 11:46:06PM +0200, Linus Walleij wrote:
>> This makes it possible for engines to implement slave transfers
>> to be done to/from a simple kmalloc():ed memory buffer and not
>> just from scatterlists.
>
> Why is this needed?  Drivers can just pass in a single-entry scatterlist
> to the existing API to achieve the same functionality, and a couple of
> them already do so.

Because of the overhead, simply. Especially if you want to trigger
many jobs after each other. (This is necessary in device/slave-DMA
since every transaction may fail...) It's not just constructing the
sg-headers and freeing them again and again, it's also list traversals
here and there since the driver must assume it can be a linked sglist and
then two other list traversals for each
dma_map_sg()/dma_unmap_sg() pair and ... yeah that's basically
it.

And the number of extra code lines needed.

Then it's something conceptwise of creating a list that you know
is just always one element that is just not elegant, like taking a queue
numer and standing in queue when there is only one customer but
hey, maybe it's just me.

One way of achieving it for all present drivers is to wrap the passed
buffer in a single sglist and pass to the sglist function if the single
buffer call is not supported in the driver. Maybe it'd be better if I
coded up the patch like that so all driver can rely on this function
to be present?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ