From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753903AbdBRUKr (ORCPT ); Sat, 18 Feb 2017 15:10:47 -0500 Received: from mail-qk0-f194.google.com ([209.85.220.194]:33830 "EHLO mail-qk0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753461AbdBRUKp (ORCPT ); Sat, 18 Feb 2017 15:10:45 -0500 MIME-Version: 1.0 In-Reply-To: <1CC272501B5BC543A05DB90AA509DED50AF5EC@fmsmsx122.amr.corp.intel.com> References: <1487175261-7051-1-git-send-email-atull@kernel.org> <1487175261-7051-8-git-send-email-atull@kernel.org> <20170215172157.GA3317@obsidianresearch.com> <20170215180612.GB3317@obsidianresearch.com> <20170215203734.GC5531@obsidianresearch.com> <20170218023010.GA8244@live.com> <1CC272501B5BC543A05DB90AA509DED50AF5EC@fmsmsx122.amr.corp.intel.com> From: Alan Tull Date: Sat, 18 Feb 2017 14:10:43 -0600 Message-ID: Subject: Re: [RFC 7/8] fpga-region: add sysfs interface To: "Nadathur, Sundar" Cc: Moritz Fischer , Yves Vandervennet , Jason Gunthorpe , "matthew.gerlach@linux.intel.com" , linux-kernel , "linux-fpga@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v1IKAv8q003822 On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar wrote: > 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 Hi Sundar, IIUC, each field is position dependent. One of the strengths of key value pairs is that any key can be added in any order and ones that aren't applicable for a particular architecture or use case can be left out. If the header is position dependent, it becomes less flexible. Once a field is added, we are stuck with it forever unless we drop it in some incremented version of the header format. Alan