linux-kernel - Re: [RFC PATCH v2 0/1] FPGA subsystem core

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:	Fri, 04 Oct 2013 19:44:22 +0200
From:	Michal Simek <monstr@...str.eu>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Pavel Machek <pavel@...x.de>,
	Michal Simek <michal.simek@...inx.com>,
	linux-kernel@...r.kernel.org, Alan Tull <atull@...era.com>,
	Dinh Nguyen <dinguyen@...era.com>,
	Philip Balister <philip@...ister.org>,
	Alessandro Rubini <rubini@...dd.com>,
	Steffen Trumtrar <s.trumtrar@...gutronix.de>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Jason Cooper <jason@...edaemon.net>,
	Yves Vandervennet <rocket.yvanderv@...il.com>,
	Kyle Teske <kyle.teske@...com>,
	Josh Cartwright <joshc@....teric.us>,
	Nicolas Pitre <nico@...aro.org>,
	Mark Langsdorf <mark.langsdorf@...xeda.com>,
	Felipe Balbi <balbi@...com>, linux-doc@...r.kernel.org,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	David Brown <davidb@...eaurora.org>,
	Rob Landley <rob@...dley.net>,
	"David S. Miller" <davem@...emloft.net>,
	Joe Perches <joe@...ches.com>,
	Cesar Eduardo Barros <cesarb@...arb.net>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH v2 0/1] FPGA subsystem core

On 10/04/2013 06:46 PM, H. Peter Anvin wrote:
> On 10/04/2013 07:28 AM, Michal Simek wrote:
>> On 10/04/2013 04:21 PM, H. Peter Anvin wrote:
>>> Yes; I never got too corner Greg ;)
>>>
>>> Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
>>>> On Fri, Oct 04, 2013 at 03:57:57PM +0200, Michal Simek wrote:
>>>>> But anyway what was resolution from that meeting?
>>>>
>>>> It never happened, we got distracted by lunch :)
>>
>> Then why not to have it here?
>>
> 
> The essential question is if the firmware interface really is
> appropriate for FPGAs.  It definitely has a feel of a "square peg in a
> round hole", especially when you consider the myriad ways FPGAs can be
> configured (some persistent, some not, some which takes effect now,
> some which come later, some which involve bytecode interpreters...)
> and considering reconfiguration and partial reconfiguration.

If you look at it in general I believe that there is wide range
of applications which just contain one bitstream per fpga and the bitstream is replaced
by newer version in upgrade. For them firmware interface should be pretty useful.
Just setup firmware name with bitstream and it will be automatically loaded in
startup phase.

Then there is another set of applications especially in connection to partial reconfiguration
where this can be done statically by pregenerated partial bitstreams
or automatically generated on target cpu. For doing everything on the target
firmware interface is not the best because everything can be handled by user application
and it is easier just to push this bitstream to do device and not to save it
to the fs.

I think the question here is if this subsystem could have several interfaces.
For example Alan is asking for adding char support.
Does it even make sense to have more interfaces with the same backend driver?
When this is answered then we can talk which one make sense to have.
In v2 is sysfs and firmware one. Adding char is also easy to do.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform

Download attachment "signature.asc" of type "application/pgp-signature" (264 bytes)