From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Date: Fri, 21 Dec 2007 11:17:47 +1100 Subject: [U-Boot-Users] RFC: New U-boot image format In-Reply-To: <476AEF2A.6090805@freescale.com> References: <475EB857.4080104@semihalf.com> <475EE3AE.6060102@ge.com> <4761B528.3080601@semihalf.com> <47692A03.6030700@semihalf.com> <20071220005010.GA23395@localhost.localdomain> <476A9B35.3020309@freescale.com> <476AEBF7.2030807@semihalf.com> <476AEF2A.6090805@freescale.com> Message-ID: <20071221001747.GE2665@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Dec 20, 2007 at 04:39:38PM -0600, Scott Wood wrote: > Marian Balakowicz wrote: >> I was thinking of a syntax that would be similar to regular data >> sections which are enclosed in [] braces. Something like: >> prop = {/path/to/file}; > > This one overloads {} based primarily on whether there's an equal sign > before it... a bit icky. Plus, sooner or later we'll run out of special > characters to assign meaning to, and we'll become Perlish in the process. > :-) Indeed. Plus I'd liked to keep { } consistently for delimiting lexical contexts which will accept node or property names without quoting. Plus you can't even count on the { being after an =, because you could have: prop = "a string followed by", {/a/file}; > I went with text-between slashes as it's an already-established keyword > marker. > >> or prop = [file:/path/to/file]; > > This is ambiguous; file: will be scanned as a label unless we give > precedence to it as a keyword, and I don't think we want to go down the > path of reserved words when we have other mechanisms available to separate > the namespaces. And it's gratuitously similar to bytestring notation. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson