linux-kernel - Re: [patch 1/5] Staging: VME Framework for the Linux Kernel

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090811204835.GA9910@braap.org>
Date:	Tue, 11 Aug 2009 22:48:35 +0200
From:	"Emilio G. Cota" <cota@...ap.org>
To:	Martyn Welch <martyn.welch@...anuc.com>
Cc:	Greg K-H <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	devel@...uxdriverproject.org,
	Sebastien Dugue <sebastien.dugue@...l.net>
Subject: Re: [patch 1/5] Staging: VME Framework for the Linux Kernel

Martyn Welch wrote:
> need for both approaches. It may be more efficient for a driver to use  
> and move 1 window to position it's self over the registers of each of a  
> number of compatible devices as required.

No, drivers should know nothing about the bridge. The *very* same
driver should run on different crates, different configurations,
different bridges.

The bridge should be intelligent enough to handle the driver's
mapping requests in an efficient way; it's basically the only
job of the bridge: to serve efficiently the driver's needs.
And, sorry to repeat myself, he's the only player entitled to
do so. "Because he knows better."

FWIW, our driver does exactly that. Will post it fairly soon,
but I want to test it with the new changes first.

Best wishes,
E.
--
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/