linux-kernel - Re: [PATCH v2 2/3] fpga manager: framework 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]

Message-ID: <5486FC4B.5080106@monstr.eu>
Date:	Tue, 09 Dec 2014 14:42:35 +0100
From:	Michal Simek <monstr@...str.eu>
To:	Grant Likely <grant.likely@...aro.org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
CC:	Pavel Machek <pavel@...x.de>, atull <atull@...nsource.altera.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	"H. Peter Anvin" <hpa@...or.com>, Michal Simek <monstr@...str.eu>,
	Michal Simek <michal.simek@...inx.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	Rob Herring <robh+dt@...nel.org>,
	Ira Snyder <iws@...o.caltech.edu>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>,
	Philip Balister <philip@...ister.org>,
	rubini <rubini@...dd.com>,
	Steffen Trumtrar <s.trumtrar@...gutronix.de>,
	Jason <jason@...edaemon.net>, kyle.teske@...com,
	Nicolas Pitre <nico@...aro.org>,
	"Balbi, Felipe" <balbi@...com>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	David Brown <davidb@...eaurora.org>,
	Rob Landley <rob@...dley.net>,
	David Miller <davem@...emloft.net>, cesarb@...arb.net,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Alan Tull <delicious.quinoa@...il.com>,
	dinguyen@...nsource.altera.com,
	Yves Vandervennet <yvanderv@...nsource.altera.com>
Subject: Re: [PATCH v2 2/3] fpga manager: framework core

On 12/09/2014 02:11 PM, Grant Likely wrote:
> On Mon, Dec 8, 2014 at 10:55 PM, One Thousand Gnomes
> <gnomes@...rguk.ukuu.org.uk> wrote:
>> On Sat, 6 Dec 2014 13:00:17 +0000
>> Grant Likely <grant.likely@...aro.org> wrote:
>>
>>> On Fri, Oct 24, 2014 at 11:52 AM, Pavel Machek <pavel@...x.de> wrote:
>>>> Hi!
>>>>
>>>>> * /sys/class/fpga_manager/<fpga>/firmware
>>>>>   Name of FPGA image file to load using firmware class.
>>>>>   $ echo image.rbf > /sys/class/fpga_manager/<fpga>/firmware
>>>>
>>>> I .. still don't think this is good idea. What about namespaces?
>>>> The path corresponds to path in which namespace?
>>>
>>> I don't understand your concern here. This allows userspace to name
>>> the FPGA bitstream that the kernel will use during request_firmware(),
>>> and it will show up as the $FIRMWARE value in the uevent file, but it
>>> is still the responsibility of userspace to choose what to load, and
>>> it can freely ignore the setting of $FIRMWARE if it needs to.
>>
>> I think the entire model here is basically pedicated on a bogus
>> assumption that an FPGA is a one shot device. It's not. It's a fast
>> reloadable reusable device. A lot of work being done with FPGAs in
>> operating systems already involves basically task switching and
>> scheduling FPGAs as a shared resource pool. Trying to nail something
>> together with request_firmware is several years behind the curve.
>>
>> From userspace it needs to be a open, load, use, close type model, not a
>> static or semi-static pile of mappings.
> 
> If FPGA is a general purpose resource hanging off the side that
> applications can use, then sure, but the majority of FPGA usage does
> not fall into that scenario*. The majority of FPGA usage that I've
> seen has core parts of the system implemented in the FPGA fabric.
> Video pipelines, network switching, dma to/from main memory, control
> of dedicated hardware. It's more than merely an application being able
> to use the FPGA as an accelerator.
> 
> I'm certainly not dismissing the concept of FPGA scheduling and being
> able to 'task switch' between bitstreams. Yes that is important, but
> for most users it really does look like, as you say, "a static or
> semi-static pile of mappings".
> 
> * Altera and Xilinx people - correct me if you disagree.

We need to start to walk before we can run. We should move the part of this
patch series to drivers/staging directory. Greg is OK with that and
start to adding drivers for current drivers.
Static use case is good start and we should move forward not to stay in circle.

I have some changes to this series internally which should be done.
Please give me some days to finish other work and we can move.

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" (199 bytes)