From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31595 invoked by alias); 21 Aug 2014 01:25:59 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 31578 invoked by uid 89); 21 Aug 2014 01:25:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 21 Aug 2014 01:25:57 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2375733F5F3; Thu, 21 Aug 2014 01:25:55 +0000 (UTC) From: Mike Frysinger To: Joel Brobecker Cc: gdb@sourceware.org, Joel Sherrill , Anthony Green Subject: Re: integrating dtc into the sim/ tree Date: Thu, 21 Aug 2014 01:25:00 -0000 Message-ID: <2642309.RSytPSsbtK@vapier> User-Agent: KMail/4.13.3 (Linux/3.14.2; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20140820160635.GK4828@adacore.com> References: <53F27ADC.4070609@oarcorp.com> <1850909.FvmpfGFofc@vapier> <20140820160635.GK4828@adacore.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7674596.oaumXPsFLW"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00103.txt.bz2 --nextPart7674596.oaumXPsFLW Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Content-length: 2737 On Wed 20 Aug 2014 18:06:35 Joel Brobecker wrote: > > moxie is the only one that hard requires dtc (it might be limited to > > maintainer mode). but the larger point is to delete a large body of > > custom code that the sim has today for parsing its device tree like > > data format and convert over to the standard format that the rest of > > the world is using now. and longer term, make it so we can share dtc > > files between linux/u-boot/qemu such that you can feed a fdt to the > > sim and it'll automatically bring up hardware in the same way as the > > kernel would have found it. > >=20 > > atm, you have to basically write two different device trees with > > different syntax and names, then feed one to the sim and the other to > > the kernel. and hope they don't get out of sync :). > >=20 > > there's basically no chance of people rewriting the existing sim code > > so that it gains all the same functionality as the public dtc, and > > then keeping it in sync. i'd rather just gut it and be done, and get > > the dtc updates for free. >=20 > My 2 cents: This sounds interesting, but on the other hand, I have > this feeling that requiring dtc might be a big ask. I'm not sure > how portable the dtc project is, and how easy it is to get it > installed. I went to the "Device Tree Compiler" page you referenced, > and it doesn't give at all the impression of being a mature and > widespread project... For instance, I was looking for the documentation > in order to check for things like installation, OS support, > requirements, etc. I ended up looking inside the source tree itself, > and found Documentation/manual.txt and README, but none of them answered > any of these questions. I am also wondering about releases and such, > but couldn't really find much about it. it's pretty mature imo. lemme phrase it this way: it's a hard requirement= =20 nowadays for ARM on Linux, so it's def viable. i think a lot of the docs=20 you're referring to is because the library aims to be used literally=20 everywhere -- vendor BIOS, vendor kernels, etc... the license readme expla= ins=20 this a bit more: https://git.kernel.org/cgit/utils/dtc/dtc.git/tree/README.license > I hope this explains why I would personally feel a little more > comfortable if that dependency remained optional. >=20 > Now, if the project was really super easy to install and completely > portable (think Linux & Windows, of course, but also Darwin, > Solaris...), I would consider making it mandatory. i'd be willing to make sure it builds everywhere. the external dependencie= s=20 in libfdt are extremely light (by design -- it wants to work in your typica= l=20 BIOS). basically it needs str/mem funcs and not ancient stdint.h. -mike= --nextPart7674596.oaumXPsFLW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJT9UqoAAoJEEFjO5/oN/WBGlcQAKTx5he3jXuNLt7mIXyfuzIK jQVgUCWeKjbgU7n0btaZEFZbj88MXw4fqgOgRawyx6wKoO0B0QVkctAO9MJ71Pig vXWcY/EvoUBhz8C5+1FxgZfCcMXAqbOGql66HW8+eS+cVTCMYSiO2p7MjLnX+i5w QmC10xHpfP888GCn0sNI/b8fMqI7j8hUMREHSRmp07vyJSXDWe5jo1CC95BqNoXo Fg0jnyKSOYIGSff/MXEs3NgSu9IqcjayhpQK3TY8X00aVXjohgoWzJfk6iS9gzwK oztSHI+pNSOEY294JgK5KG1YYuJMJnb3ZXCJE+kZ/EcoiE68raOpzpKYN1F9fOgt On+sdc3lo7TfmnEucc1pHyAVoqNzaYkj5CIzfVJW7ngUTAxzbTpGvoMApoILxuPS iKd0LsNRyhbvHXD+8dLa3AQErvrpNMa1vD6DBY7MOgiW9JZq6Z5u/R5aDrL2DVh7 AaPYyoqSUC8luuJW397UVdmxcPCN8yOyunLYJQK9AIXGdP4rlP0jtL5TY8ImslXm ks4TGCcIdV5Md4Iff4uxpnCMbJTTl8zNj7/yGt8IidpToiYXR9Pl/K4JioRA4RB+ nNOZtU3217LbQ1qntIXDxFC1zJqNhjES5dM23lIMUC/Jz/tRWBrmFV3e853wrSV6 8JHqL2klFiAW60vVC0ZL =218J -----END PGP SIGNATURE----- --nextPart7674596.oaumXPsFLW--