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-next>] [day] [month] [year] [list]
Message-ID: <1CC272501B5BC543A05DB90AA509DED50B25C9@fmsmsx122.amr.corp.intel.com>
Date:   Fri, 24 Feb 2017 21:41:12 +0000
From:   "Nadathur, Sundar" <sundar.nadathur@...el.com>
To:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        "Li, Yi" <yi1.li@...ux.intel.com>
CC:     Moritz Fischer <moritz.fischer@...us.com>,
        Alan Tull <atull@...nel.org>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: RE: [RFC] Add a parser in fpga_region to decode the tlv meta data
 suggested by Sundar

On Friday, February 24, 2017 1:17 PM, Jason Gunthorpe wrote:
> Do we need binary data in the header?
> 
> Jason

I have talked about the need for structs and arrays, potentially nested, without really explaining why we may need them eventually. I'll get to that in a moment. But, can we agree that, if nested structs, arrays and general extensibility is needed, FDT or TLVs would be the way to go? If we agree, it becomes a FDT vs. TLV discussion.

Here's why I think we may need extensibility. (Pardon me for starting from the basics -- just trying to set the background.) A FPGA can be programmed as a whole, or can have Partial Reconfiguration (PR) regions, which can be programmed independently. The image programmed into a PR region may have components and sub-units in general. These components may have their own properties. For example, if the FPGA is exposed as a PCIe device to the host, the components may have their own registers in MMIO, DMA attributes and/or interrupts. They may also have identifiers describing their function. In general, we may want these attributes and properties, on  a per-component basis, in the metadata. Even if we don't need them tomorrow, as data center and IOT needs grow, we are likely to need that going forward. 

We could then model the properties of a component as a struct, and the set of components then becomes either an array of structs or a struct of structs. I am not trying to pick a specific object model here-- just mentioning the possibilities. 

IMHO, KVPs are good for scalar quantities. But, when we get to nested arrays/structs, we would need a tree-structured data model, such as TLVs or FDTs. 

Please let me know what you think.

Regards,
Sundar

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ