From: "Nadathur, Sundar" <firstname.lastname@example.org>
To: Moritz Fischer <email@example.com>,
Yves Vandervennet <firstname.lastname@example.org>
Cc: Jason Gunthorpe <email@example.com>,
"Alan Tull" <firstname.lastname@example.org>,
Subject: RE: [RFC 7/8] fpga-region: add sysfs interface
Date: Sat, 18 Feb 2017 12:45:49 +0000 [thread overview]
Message-ID: <1CC272501B5BC543A05DB90AA509DED50AF5EC@fmsmsx122.amr.corp.intel.com> (raw)
On February 17, 2017 6:30 PM, Moritz Fischer wrote:
On Fri, Feb 17, 2017 at 04:28:37PM -0600, Yves Vandervennet wrote:
> whatever solution we decide to go with has to work with other OS'es.
> The last thing we want to do is to have wrappers that are Linux specific.
I do agree that we should make sure the format is reasonably well documented. In my earlier email I pointed out several projects successfully integrating libfdt.
There's nothing Linux specific about libfdt. FreeBSD uses it, U-Boot, Qemu ...
I know nothing about how windows kernel development works, but I assume however one goes about making FPGA programming work there, someone will most likely have to write a kernel mode driver to take the job of the fpga-mgr framework.
I assume this will be written in C or C++ or whatever people use these days for kernel development so pulling in libfdt shouldn't be too hard if we were to try that.
To be clear:
I did not suggest fdt to make it hard for other OSs, or because this is my personal pet project. I think we're more likely to get it right by reusing an existing format, with parsers that other people already successfully use. It does not have to be fdt (I suggested that because that was around), but I do think we certainly can do better than HTTP-eque plaintext headers.
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html
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,
next prev parent reply other threads:[~2017-02-18 12:45 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-15 16:14 FPGA Region enhancements and fixes Alan Tull
2017-02-15 16:14 ` [RFC 1/8] fpga-mgr: add a single function for fpga loading methods Alan Tull
2017-02-16 0:36 ` matthew.gerlach
2017-02-15 16:14 ` [RFC 2/8] fpga-region: support more than one overlay per FPGA region Alan Tull
2017-02-16 16:50 ` matthew.gerlach
2017-02-16 17:35 ` Alan Tull
2017-02-15 16:14 ` [RFC 3/8] fpga-bridge: add non-dt support Alan Tull
2017-02-15 16:14 ` [RFC 4/8] doc: fpga-mgr: separate getting/locking FPGA manager Alan Tull
2017-02-17 17:14 ` Li, Yi
2017-02-17 21:55 ` Alan Tull
2017-02-17 17:52 ` Moritz Fischer
2017-02-17 22:02 ` Alan Tull
2017-02-15 16:14 ` [RFC 5/8] " Alan Tull
2017-02-15 16:14 ` [RFC 6/8] fpga-region: separate out common code to allow non-dt support Alan Tull
2017-02-15 16:14 ` [RFC 7/8] fpga-region: add sysfs interface Alan Tull
2017-02-15 17:21 ` Jason Gunthorpe
2017-02-15 17:46 ` Alan Tull
2017-02-15 17:55 ` Moritz Fischer
2017-02-15 18:06 ` Jason Gunthorpe
2017-02-15 18:23 ` Alan Tull
2017-02-15 18:31 ` Moritz Fischer
2017-02-15 19:49 ` Jason Gunthorpe
2017-02-15 22:49 ` Alan Tull
2017-02-15 23:07 ` Jason Gunthorpe
2017-02-15 20:07 ` matthew.gerlach
2017-02-15 20:37 ` Jason Gunthorpe
2017-02-15 20:54 ` Moritz Fischer
2017-02-15 21:15 ` Jason Gunthorpe
2017-02-15 21:36 ` Moritz Fischer
2017-02-15 22:42 ` Alan Tull
2017-02-16 0:16 ` Moritz Fischer
2017-02-16 17:47 ` Alan Tull
2017-02-16 17:56 ` Jason Gunthorpe
2017-02-16 18:11 ` Moritz Fischer
2017-02-17 22:28 ` Yves Vandervennet
2017-02-18 2:30 ` Moritz Fischer
2017-02-18 12:45 ` Nadathur, Sundar [this message]
2017-02-18 20:10 ` Alan Tull
2017-02-18 20:45 ` Moritz Fischer
2017-02-19 15:00 ` Alan Tull
2017-02-19 23:16 ` Alan Tull
2017-02-20 23:49 ` Moritz Fischer
2017-02-21 18:33 ` Alan Tull
2017-02-22 3:13 ` Nadathur, Sundar
2017-02-22 3:49 ` Moritz Fischer
2017-02-22 5:12 ` Jason Gunthorpe
2017-02-22 5:38 ` Moritz Fischer
2017-02-22 5:46 ` Nadathur, Sundar
2017-02-22 6:05 ` Moritz Fischer
2017-02-22 16:44 ` Jason Gunthorpe
2017-02-22 17:50 ` Moritz Fischer
2017-02-22 17:54 ` Jason Gunthorpe
2017-02-22 17:57 ` Moritz Fischer
2017-02-22 16:33 ` Alan Tull
2017-02-22 16:44 ` Moritz Fischer
2017-02-22 16:52 ` Alan Tull
2017-02-27 20:09 ` Alan Tull
2017-02-27 22:49 ` Moritz Fischer
2017-02-28 0:04 ` matthew.gerlach
2017-02-15 21:20 ` Anatolij Gustschin
2017-02-15 16:14 ` [RFC 8/8] doc: fpga: add sysfs document for fpga region Alan Tull
2017-02-28 17:35 ` FPGA Region enhancements and fixes Alan Tull
2017-02-28 22:03 ` Alan Tull
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.