linux-kernel - Re: [RFC v2 2/5] 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: <20080131084433.GA14160@linux-sh.org>
Date:	Thu, 31 Jan 2008 17:44:33 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	David Brownell <david-b@...bell.net>
Cc:	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org,
	Shannon Nelson <shannon.nelson@...el.com>,
	kernel@...32linux.org, Francis Moreau <francis.moro@...il.com>,
	"Vladimir A. Barinov" <vbarinov@...mvista.com>,
	Pierre Ossman <drzeus-list@...eus.cx>
Subject: Re: [RFC v2 2/5] dmaengine: Add slave DMA interface

On Thu, Jan 31, 2008 at 12:27:24AM -0800, David Brownell wrote:
> On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> > So basically, you're asking for maximum flexibility with minimum
> > overhead.  I agree that should be the ultimate goal, but wouldn't it
> > be better to start with something more basic?
> 
> Where you start is often NOT where you end up!  You should make sure
> that a wants-to-be-generic slave interface can accomodate a variety of
> non-basic mechanisms, without getting bloated.  :)
> 
I agree with Haavard here. The original dmaengine code was sparse at best
and for a very specific type of workload, evolving that in to something
that can be used by far more people with minimal pain is a good first
step. Trying to overengineer it from the beginning to accomodate fringe
controllers that already have an established API pretty much blocks the
vast majority of users for this work. It also adds in additional
complexity that is simply unnecessary for most of the controllers out
there.

Flexibility is a nice thing to have, but there's absolutely no reason to
penalize all of the other users for this due to the fact that OMAP wants
to be different. Perhaps rather than reinventing the OMAP DMA framework,
it would make more sense to just provide a dmaengine driver that wraps in
to it. You're ultimately going to be dealing with a reduced set of
functionality, but users that need to hook in to all of the quirks of the
hardware are going to be special-cased drivers anyways.
--
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/