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

Date:	Tue, 7 Jul 2015 09:13:36 +0200
From:	Alessio Igor Bogani <alessioigorbogani@...il.com>
To:	devel@...verdev.osuosl.org
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality

Hi Dmitry,

On 6 July 2015 at 19:24, Dmitry Kalinkin <dmitry.kalinkin@...il.com> wrote:
[...]
>
> I'm not a VME expert, but it seems that VME windows are a quiet limited resource
> no matter how you allocate your resources. Theoretically we could put up to 32
> different boards in a single crate, so there won't be enough windows for each
> driver to allocate. That said, there is no way around this when putting together
> a really heterogeneous VME system. To overcome such problem, one could
> develop a different kernel API that would not provide windows to the
> drivers, but
> handle reads and writes by reconfiguring windows on the fly, which in turn would
> introduce more latency.

In my humble opinion using user-space drivers (as workaround for
limited windows/images) introduce more latency than let VME driver
dynamically configure windows/images. After all VME systems usually
aren't so much dynamic by its nature (Who likes continuously put in
and out a board which requires an insertion force between 20 and 50
kg?) and are instead heavily used in critical contexts often in
non-stop way.

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.

Until now we have used a modified version of the old vmelinux.org
stack for sharing windows/images between all (ours) VME kernel drivers
and we would be very happy to see something similar in vanilla (at
least coalescence two adjacent addresses with same modifiers).

> Those who need such API are welcome to develop it :)

I would be glad to try it if the maintainer is willing to receive this
type of changes.

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/