From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11367 invoked by alias); 20 Aug 2014 16:11:21 -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 11358 invoked by uid 89); 20 Aug 2014 16:11:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: OARmail.OARCORP.com Received: from oarmail.oarcorp.com (HELO OARmail.OARCORP.com) (67.63.146.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Aug 2014 16:11:19 +0000 Received: from [192.168.1.44] (192.168.1.44) by OARmail.OARCORP.com (192.168.2.2) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 20 Aug 2014 11:04:54 -0500 Message-ID: <53F4C8A5.1070503@oarcorp.com> Date: Wed, 20 Aug 2014 16:11:00 -0000 From: Joel Sherrill User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joel Brobecker , Mike Frysinger CC: "gdb@sourceware.org" , Anthony Green Subject: Re: integrating dtc into the sim/ tree References: <53F27ADC.4070609@oarcorp.com> <1732783.0nBxt22mln@vapier> <20140820095347.GH4828@adacore.com> <1850909.FvmpfGFofc@vapier> <20140820160635.GK4828@adacore.com> In-Reply-To: <20140820160635.GK4828@adacore.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00100.txt.bz2 On 8/20/2014 11:06 AM, 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. >> >> 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 :). >> >> 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. > 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. > > I hope this explains why I would personally feel a little more > comfortable if that dependency remained optional. > > 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 would have been happy if the generated files were in the tree and only maintainer mode would result in the dependencies being checked. This has precedence for other tools. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherrill@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985