From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754869AbdBVQ7X (ORCPT <rfc822;w@1wt.eu>);
        Wed, 22 Feb 2017 11:59:23 -0500
Received: from mail-qk0-f196.google.com ([209.85.220.196]:33502 "EHLO
        mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754247AbdBVQ7N (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 22 Feb 2017 11:59:13 -0500
MIME-Version: 1.0
In-Reply-To: <CAAtXAHfnYd0iWVK6HaAzgvwV5PN5jYYSXnxEAqDoYMiPKeR8nQ@mail.gmail.com>
References: <20170218023010.GA8244@live.com> <1CC272501B5BC543A05DB90AA509DED50AF5EC@fmsmsx122.amr.corp.intel.com>
 <CANk1AXT7EMDw-5qWqKCDJcwySQjhhVGf_1m-b9NTbyzVRkO7cg@mail.gmail.com>
 <20170218204509.GA32544@live.com> <CANk1AXTCi6ccimHmXrNPXUn_MJBAoserCmC2kmapQ3Y=zjM79w@mail.gmail.com>
 <CANk1AXTVuVJR6mAKPWgs-+fyRRU1akgmYidu2ubcGJXAwu0oBQ@mail.gmail.com>
 <CAAtXAHd5C4yz3s0WZBL_YKjhwEEntbowsvfg1GUdRDbnq+t9zg@mail.gmail.com>
 <CANk1AXQxpcbGm-MrjrE-7FCmnXAW=Cieg+8QV6ypc6OSCLHTQg@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED50B005A@fmsmsx122.amr.corp.intel.com>
 <CAAtXAHdBv4Q_WykwBS7yXkRH=DnyPBjCmv+V91Jexr32Pf_WOQ@mail.gmail.com>
 <20170222051201.GB29755@obsidianresearch.com> <CAAtXAHe-3L4E7sj9RJJwgMEASJCFmYcXyJdm6z7NtnXWGVGG=w@mail.gmail.com>
 <CANk1AXT2hpjHRWaqunnWzqu48m212zE11zFGhiu68G9zRcXAOw@mail.gmail.com> <CAAtXAHfnYd0iWVK6HaAzgvwV5PN5jYYSXnxEAqDoYMiPKeR8nQ@mail.gmail.com>
From: Alan Tull <delicious.quinoa@gmail.com>
Date: Wed, 22 Feb 2017 10:52:12 -0600
Message-ID: <CANk1AXQVVsUf4QpA=Bt7Hsuxy+8M9bEYk90xX9Ux+U4vaQiKeg@mail.gmail.com>
Subject: Re: [RFC 7/8] fpga-region: add sysfs interface
To: Moritz Fischer <moritz.fischer@ettus.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
        "Nadathur, Sundar" <sundar.nadathur@intel.com>,
        Yves Vandervennet <yves.vandervennet@linux.intel.com>,
        "matthew.gerlach@linux.intel.com" <matthew.gerlach@linux.intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        "linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
        "Marek Va??ut" <marex@denx.de>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Feb 22, 2017 at 10:44 AM, Moritz Fischer
<moritz.fischer@ettus.com> wrote:
> On Wed, Feb 22, 2017 at 8:33 AM, Alan Tull <delicious.quinoa@gmail.com> wrote:
>> On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer
>> <moritz.fischer@ettus.com> wrote:
>>
>> Hi Moritz,
>>
>>> Hi all,
>>>
>>> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
>>> <jgunthorpe@obsidianresearch.com> wrote:
>>>> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
>>>>
>>>>> 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).
>>>>
>>>> tlv/fdt/http headers are all essentially exactly the same
>>>> thing. Key/value pairs with various encoding schemes.
>>>>
>>>> I don't think we don't need a tree of data, so fdt is overkill.
>>>>
>>>> tlv is not substantially easier to parse correctly than the
>>>> structured plain text headers.. It is just in binary so it can
>>>> represent binary-ish things better.
>>>
>>> TLV Seems easy enough. To give an update, I played with fdt a bit to see
>>> how far I get in half an hour. I got bool / int / strings to work
>>> quite fast (~30mins).
>>
>> Thanks for doing this fast piece of exploratory coding.  It does
>> confirm that for Linux, using fdt is pretty straightforward here.
>> However...
>>
>>> Please disregard the horrible hackyness of this ...
>>>
>>> For simplicity I stuck the header on top of my bitfile with:
>>>
>>> <snip>
>>> /dts-v1/;
>>>
>>> /{
>>>         description = "Test";
>>>         compressed = <0>;
>>>         encrypted = <1>;
>>> };
>>
>> I understand that this is a simplified example, but it looks a lot
>> like KVP which then gets compiled by dtc.
>>
>> If we do KVP or TLV we get skip using dtc, which would be nice for non-dt
>> OS's using the same images.
>
> I used dtc for pure lazyness. Writing a blob to a file using libfdt is
> about as much
> code as parsing it.

Thanks for that clarification.  I haven't used libfdt myself.  That
takes care of the license issue I brought up below.

I have heard that MS is averse to using DT, but I'm not clear
about why other than that it isn't native to Windows already.

Alan

> Even with KVP or TLV you have some code that needs
> to encode / pack your header into a file.
>
> libfdt has an example that creates an empty tree. Write that to a file, done.
>
> 1: Create empty tree
> https://github.com/dgibson/dtc/blob/master/libfdt/fdt_empty_tree.c
>
> 2: fopen / fwrite, done
>
>> Also, the license of libfdt allows the use by proprietary
>> os's, but that's not true for dtc.
>
> Why would that be an issue, you don't need to link anything to run
> dtc. That being
> said as I pointed out above you don not have to actually use dtc if the values
> are known ahead of time (like in our case). What you'd get from using dtc is to
> encode arbitrary values (for the types supported).
>
> Cheers,
>
> Moritz