linux-kernel - Re: [RFC v3 4/7] dmaengine: Add slave DMA interface

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: <e9c3a7c20802181442q60d94a77rfff8ce4a9f3087b3@mail.gmail.com>
Date:	Mon, 18 Feb 2008 15:42:07 -0700
From:	"Dan Williams" <dan.j.williams@...el.com>
To:	"Haavard Skinnemoen" <hskinnemoen@...el.com>
Cc:	linux-kernel@...r.kernel.org,
	"Shannon Nelson" <shannon.nelson@...el.com>,
	"David Brownell" <david-b@...bell.net>, kernel@...32linux.org,
	"Francis Moreau" <francis.moro@...il.com>,
	"Paul Mundt" <lethal@...ux-sh.org>,
	"Vladimir A. Barinov" <vbarinov@...mvista.com>,
	"Pierre Ossman" <drzeus-list@...eus.cx>
Subject: Re: [RFC v3 4/7] dmaengine: Add slave DMA interface

On Feb 18, 2008 6:22 AM, Haavard Skinnemoen <hskinnemoen@...el.com> wrote:
> On Sat, 16 Feb 2008 13:06:54 -0700
> "Dan Williams" <dan.j.williams@...el.com> wrote:
>
> > I like the direction of the patch, i.e. splitting out separate
> > functionality into separate structs.  However, I do not want to break
> > the model of clients sourcing the operations and drivers sinking them
> > which dma_slave_descriptor appears to do.  How about adding a
> > scatterlist pointer and an 'unmap_type' to the common descriptor?
> > Where unmap_type selects between,  page, single, sg, or no-unmap.
> > Drivers already know the length and direction.
>
> But there are currently no operations available for submitting
> scatterlists as a single descriptor -- the client iterates over the
> scatterlist and submits one descriptor for each entry. So there's no
> way you can associated a scatterlist with a single descriptor. You can
> perhaps attach it to the last one, but that may get you into trouble if
> the transfer is terminated early for some reason.
>

Drivers know how to treat a group of descriptors as one operation.  I
see this as no different than the case where an operation exceeds the
hardware's per descriptor max transfer length.  The driver internally
creates extra descriptors but the client only needs to worry about one
handle.

[..]

> Btw, this discussion is a bit off-topic for the patch in question, but
> it's an issue that needs to be resolved.
>

Agreed, more code less words :-).  I'll try to brew this into a patch.

--
Dan
--
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/