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

[Moritz Fischer <moritz.fischer@ettus.com>]

On Thu, Feb 16, 2017 at 9:56 AM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> On Thu, Feb 16, 2017 at 11:47:08AM -0600, Alan Tull wrote:
>
>> > Just to clarify: I was proposing using the binary format of dts,
>> > not actually requiring devicetree for it to work. There's plenty
>> > of people running u-boot on x86 using FIT images to boot.
>>
>> The FPGA images should not be required to have OS specific parts.
>> Some ahem non-Linux OS's that use FPGAs don't use device tree, so that
>> adds an extra complication for them unnecessarily.

That's a good point, I had assumed that pulling in a C library shouldn't
be an issue for any OS (u-boot can do it, BSD can do it, Linux can do it).
I have to admit I didn't think about Windows :)

> Not just that, but we parse the bitfile headers in user space as well.
>
> Requiring people to use libfdt pretty much kills the idea because of
> its GPL license.

<snip>

libfdt, however, is GPL/BSD dual-licensed.  That is, it may be used
either under the terms of the GPL, or under the terms of the 2-clause
BSD license (aka the ISC license).  The full terms of that license are
given in the copyright banners of each of the libfdt source files.
This is, in practice, equivalent to being BSD licensed, since the
terms of the BSD license are strictly more permissive than the GPL.

</snip>

> As I've shown the plain text headers can be produced in a scripting
> langauge, and are trivially consumed without much trouble. IHMO this
> makes it more likely there would be adoption..

If you provide a reasonably well documented format and make your tools
easy to use and integrate, I don't think that would be an issue.

I was really mainly concerned about the parsing userspace provided
strings in kernel being a security issue.

If everyone else feels http style plain text is the best we can do, so be it.

I wanted to look around and see how far I get with fdt, but anyway I'm quite
busy with other work at the moment. If someone comes around and writes
code that we can review, maybe that's better than not having a solution.

I'll see how far I get, maybe it turns out my proposal is a bad idea anyways
once I start writing actual code :)

Moritz