linux-kernel - Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality

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-next>] [day] [month] [year] [list]

Date:	Tue, 7 Jul 2015 14:51:13 +0200
From:	Alessio Igor Bogani <alessioigorbogani@...il.com>
To:	Dmitry Kalinkin <dmitry.kalinkin@...il.com>
Cc:	Martyn Welch <martyn.welch@...com>, devel@...verdev.osuosl.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Igor Alekseev <igor.alekseev@...p.ru>,
	LKML <linux-kernel@...r.kernel.org>,
	Manohar Vanga <manohar.vanga@...il.com>
Subject: Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality

Hi Dmitry,

On 7 July 2015 at 12:47, Dmitry Kalinkin <dmitry.kalinkin@...il.com> wrote:
[...]
> The API I had in mind would have only vme_master_read and vme_master_write
> that would take absolute addresses (not relative to any window). These
> variants
> of access functions would then try to reuse any window that is already able
> to serve
> the request or wait for a free window and reconfigure it for the need of the
> request.
> After usage the window is to be returned back to the window pool.

Interesting approach.

> Other way to implement these would be to use DMA for everything, since it
> doesn’t
> have the limitations that the windows have.


> On 07 Jul 2015, at 10:08, Alessio Igor Bogani <alessioigorbogani@...il.com>
> wrote:
[...]
>> In fact this is a big obstacle for adoption of this VME stack (at least for
>> us). We use VME a lot and we care about latency as well so we use only
>> kernel-space drivers for ours VME boards but unfortunately the VME stack let
>> us to link a single board with a single window/image (so max 8 boards on
>> tsi148) only. That said that stack has proven to be very rock solid.
>
> Current VME stack links windows not to the boards, but to device drivers.
> Driver
> could potentially minimise window usage within it’s scope (any sort of
> window
> reusing, like mapping whole A16 once to be used with all boards), but this
> won’t
> work across multiple drivers. Even if all of your drivers are window-wise
> economic,
> they will still need some amount of windows per each driver. Not that we
> have that
> many kernel drivers...

Yes you can share a window/image between all boards of the same type
(in effect we are porting our drivers in this way) *but* it isn't the
expected way to work (see Documentation/vme_api.txt struct
vme_driver's probe() and match() functions and the GE PIO2 VME
driver).

Ciao,
Alessio
--
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/