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

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAtXAHf0+DM+3uL5_dLxFZ_VmruYZzOpi5p0yu0jQwKniHA86A@mail.gmail.com>
Date:   Tue, 21 Feb 2017 22:05:42 -0800
From:   Moritz Fischer <moritz.fischer@...us.com>
To:     "Nadathur, Sundar" <sundar.nadathur@...el.com>
Cc:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        Alan Tull <delicious.quinoa@...il.com>,
        Yves Vandervennet <yves.vandervennet@...ux.intel.com>,
        "matthew.gerlach@...ux.intel.com" <matthew.gerlach@...ux.intel.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        "Marek Va??ut" <marex@...x.de>
Subject: Re: [RFC 7/8] fpga-region: add sysfs interface

On Tue, Feb 21, 2017 at 9:46 PM, Nadathur, Sundar
<sundar.nadathur@...el.com> wrote:
> On February 21, 2017 9:39 PM, Moritz Fischer wrote:
>
>> 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).
>> Please disregard the horrible hackyness of this ...
>> [...]
>> So I'm fairly convinced I can make this work, TVLs seem like it could work,
>> too.
>>
>> > So far the only thing we know we need is a 'bool' for encrypted and a
>> > stringish guid thing for partial reconfiguration.
>
> These things have a way of growing beyond their original anticipated needs.

True. But yeah, not sure about the requirement for a tree, maybe it is overkill.

> Say we upstream a metadata parser. Subsequently, an FPGA image is released with an additional metadata field that the upstreamed version does not handle. How will this be handled if the metadata were in FDT or KVP format?

The code above will gently ignore it, as I said I spent about half an hour on
writing that, just to prove to myself it can be done easily.
Logically I don't see anything wrong with ignoring features from the future.
But if one insisted one could make a compatibility number part of the
required properties I suppose and error out instead. There are examples
of optional properties in the devicetree parsing code in the kernel.

That being said older drivers / fpga-mgr  will not deal with newer features.
TLV / KV or whatever doesn't change this fact, or am I missing something?

Adding new properties to devicetrees is a well known exercise to cope with
newer versions or variations of hardware and happens all the time in the kernel.
Older kernels will just ignore them.

Thanks,

Moritz