linux-kernel - Re: [PATCH 00/16] Intel FPGA Device Drivers

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, 18 Apr 2017 10:59:06 -0400
From:   Jerome Glisse <jglisse@...hat.com>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     Alan Tull <atull@...nel.org>,
        "Luebbers, Enno" <enno.luebbers@...el.com>,
        Moritz Fischer <moritz.fischer@...us.com>,
        Wu Hao <hao.wu@...el.com>, linux-fpga@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Kang, Luwei" <luwei.kang@...el.com>,
        "Zhang, Yi Z" <yi.z.zhang@...el.com>
Subject: Re: [PATCH 00/16] Intel FPGA Device Drivers

On Tue, Apr 18, 2017 at 02:36:06PM +0100, Alan Cox wrote:
> > Well Intel inclusion of FPGA triggered my curiosity and when that patchset
> > came accross my inbox i did wonder where the open source userspace was and
> > went looking for it to no avail. So this isn't against a specific patchset
> > but more broadly against the whole drivers/fpga/ story. Sorry if this was
> > not clear.
> > 
> > 
> > > It sounds like you are opposed to any kernel support of loading images
> > > on FPGAs until all vendors have opensource toolchains.  
> > 
> > Yes that is what i am saying. They are different standard in the kernel
> > and i would rather have one clear standard about driver needing proper
> > open source userspace to go along with any upstream driver.
> 
> So Red Hat will stop shipping any hardware with loadable firmware ?
> 
> No I thought not 8)
> 
> I think you need to be much clearer what you are talking about. The GPU's
> load closed firmware. The sound cards load closed firmware. The pieces we
> demand are open (with the exception of the rather strange position
> Debian takes) are the actual pieces you need to use the device on the
> Linux side - so the 3D libraries, 2D acceleration libraries, wifi
> interfaces, audio playback and so on.
> 
> The FPGA bitstreams are and always have been counted as firmware (nothing
> here is new except that existing systems load FPGA firmware via
> devicetree at boot rather than dynamically). That's true of the Xilinx
> drivers, the many FPGA drivers for existing ARM and other processor
> platforms containing FPGA today that are in kernel.

That is where we disagree. I do not see bitstream as firmware. For instance
now you can run OpenCL on some FPGA, so this is exactly like GPU we should
request open source stack from OpenCL down to bitstream.

 
> The second part of the equation is the tools for selecting a bitstream,
> and for running whatever accelerator you loaded. Generally that's just a
> device that mmap's the accelerator into whatever application wishes to
> bash on it. The bits you need to load a bitstream do need to be open, and
> the device driver that does the mmio mappingand there will no doubt over
> time be other drivers where you do want to kernel mediate your FPGA
> functions.

For me this is not enough (tool to load bitstream).

Jérôme