linux-kernel - Re: [RFC 7/8] fpga-region: add sysfs interface

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: <20170218023010.GA8244@live.com>
Date:   Fri, 17 Feb 2017 18:30:10 -0800
From:   Moritz Fischer <moritz.fischer@...us.com>
To:     Yves Vandervennet <yves.vandervennet@...ux.intel.com>
Cc:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        matthew.gerlach@...ux.intel.com,
        Alan Tull <delicious.quinoa@...il.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-fpga@...r.kernel.org
Subject: Re: [RFC 7/8] fpga-region: add sysfs interface

On Fri, Feb 17, 2017 at 04:28:37PM -0600, Yves Vandervennet wrote:
> Moritz,
> 
>   whatever solution we decide to go with has to work with other OS'es. The 
> last thing we want to do is to have wrappers that are Linux specific.

I do agree that we should make sure the format is reasonably well
documented. In my earlier email I pointed out several projects
successfully integrating libfdt.
There's nothing Linux specific about libfdt. FreeBSD uses it, U-Boot,
Qemu ...

I know nothing about how windows kernel development works, but I assume
however one goes about making FPGA programming work there, someone will
most likely have to write a kernel mode driver to take the job of the
fpga-mgr framework.
I assume this will be written in C or C++ or whatever people use these
days for kernel development so pulling in libfdt shouldn't be too hard
if we were to try that.

To be clear:
I did not suggest fdt to make it hard for other OSs, or because this is
my personal pet project. I think we're more likely to get it right by
reusing an existing format, with parsers that other people already
successfully use. It does not have to be fdt (I suggested that because
that was around), but  I do think we certainly can do better than
HTTP-eque plaintext headers.

Thanks,

Moritz