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

[Nadathur, Sundar]

On February 17, 2017 6:30 PM, Moritz Fischer wrote:
<quote>

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
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at  http://vger.kernel.org/majordomo-info.html
</endquote>

Hi all,
   Interesting discussion. The discussion so far has brought out many concerns such as OS independence. There is an existing format, well-known to developers, with widespread support, and which is quite extensible: Type-Length-Value triples.

To elaborate, a TLV-based format has many advantages:
* It is highly extensible in many ways
   -- You can express structures and arrays using TLVs. Our needs right now may seem limited but requirements grow over time.
   -- The space of Type values can be decomposed into standard pre-defined values that are in upstreamed code, and possibly experimental or feature-specific values.
   -- Forward compatibility: We can write parsers that can skip unexpected type values, thus allowing old parsers to work with new additions. With some tweaks, old parsers can also reject unexpected values in some ranges while accepting them in other ranges.
* It is OS-independent.
* It can be easily parsed, in kernel or user space.
* It can be validated, in terms of Type values, acceptable lengths, etc.

It  is not directly human-readable but that can be easily addressed with a tool that parses TLVs. 

Compared to some other proposals:
* Compared to DTs, TLVs are OS-independent.
* Compared to strings as key-value pairs, TLVs can express structures/arrays, can be validated, etc. 

So, I suggest we use TLVs to express metadata in image files.

Thank you very much,
Sundar Nadathur