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

[Moritz Fischer]

Hi Sundar,

On Tue, Feb 21, 2017 at 7:13 PM, Nadathur, Sundar
<sundar.nadathur@xxxxxxxxx> wrote:

>> >>> Is there a standard you are looking at?  Have you seen any use of
>> >>> TLV's in the Linux kernel you could point to?
>
> Here are some examples of TLVs in the Linux kernel:
> http://lxr.free-electrons.com/source/net/ipv6/exthdrs.c <-- includes TLV parsing code
> http://lxr.free-electrons.com/source/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
> http://lxr.free-electrons.com/source/include/sound/tlv.h
>
> In addition, some protocols like LLDP are defined in terms of TLVs. E.g.
> http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/i40e/i40e_dcb.h?v=4.4

Thanks for the examples, looks interesting. I'll do some reading.

>> >> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull <delicious.quinoa@xxxxxxxxx>
>> wrote:
>> >>> It is worth repeating that libdtc is GPL/BSD with the intent of
>> >>> allowing proprietary code to use libdtc.  So license shouldn't be a barrier.
> It is better to check with Windows folks before concluding this.

About whether they can link C code? Or whether BSD licensed code is an issue?

> I agree that device enumeration should be separated out from the metadata format considerations.
>
> I got some feedback that not everybody may be familiar with TLVs. To make the proposal more clear and specific, let me add more information here.
> * We represent every datum of interest with its Type (which indicates what it is), a Length (how many bytes it takes) and a Value (its actual value, taking as many bytes as the Length field indicates.)
> * The exact lengths of the Type and Length fields are up to us, but let us say they are 4 bytes each, for concreteness. As an example, say we want to express the function in the FPGA (crypto, compress, etc.) as a UUID (128 bits long) compliant with RFC 4122. We could have a Type of say 0x00000050 (4 bytes in all) to indicate Function UUIDs, and a Length field of 0x00000010 (16 bytes) and a value of say 3d8814d8-4ecc-4030-8415-0dea4e5e829a .
> * A Type may indicate that its value is another TLV, thus allowing nested TLVs. The nested TLV may be an array of TLVs (all of same Type) or a structure (TLVs of different Types).
>
> With a Key-Value Pair, if the parser comes across an unknown key (such as when an old parser comes across newer metadata), it would not know how to skip that KVP and move onto the next one. With TLVs, that flexibility is built in. Further, we can use bits in the Type field to indicate that it is mandatory, i.e., if the parser does not understand it, it should error out rather than skip it silently. This degree of forward compatibility is difficult to achieve with other formats.

fdt does this out of the box, too. So far I've seen nothing fdt
couldn't do (or doesn't do let's rather say).

Thanks for clarifying the TLV stuff,

Moritz