public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Bartlomiej Sieka <tur@semihalf•com>
To: Scott Wood <scottwood@freescale•com>,
	Jon Loeliger <jdl@freescale•com>,
	Kumar Gala <galak@kernel•crashing.org>,
	linuxppc-dev@ozlabs•org, jdl@jdl•com
Subject: Re: [PATCH] Add support for binary includes.
Date: Wed, 04 Jun 2008 14:36:42 +0200	[thread overview]
Message-ID: <48468C5A.6030504@semihalf.com> (raw)
In-Reply-To: <20080604041304.GD29085@yookeroo.seuss>

David Gibson wrote:
> On Fri, May 30, 2008 at 01:54:59PM -0500, Scott Wood wrote:
>> David Gibson wrote:
>>> What I don't like is the combination of the two.  Using the /word/
>>> form in (1) suggests that each /word/ is a lexically distinct symbol
>>> with functions in different contexts: consider /dts-v1/, /include/,
>>> /memreserve/ - they're all used only in their own distinct context.
>>> Use of /word/s in (2) would suggest that each /word/ is just an
>>> identifier for a different function, and should all be usable in a
>>> similar grammtical context - which won't be true of /memreserve/,
>>> /dts-v1/ and any other truly lexically distinct symbols we need to
>>> add.
>> I don't understand this conclusion -- I wouldn't expect to be able to  
>> use "for" or "while" at file scope of C code, just because I can use  
>> "struct", "int", or "sizeof" there.  The slashes are simply a way of  
>> creating reserved words, some of which happen to be function-like.
> 
> Heh, when I started revisiting this after my long hiatus doing other
> things, I was thinking the same way.  I still have a few misgivings,
> but then the nice thing about the slash-delimited reserved word thing
> is that even if we come up with a new, nicer syntax it's not going to
> hurt to keep the slash-form around for compatibility.
> 
> sizeof is an interesting example.  As you point out it's an example of
> a function-like reserved word, which given our existing approach to
> reserved words supports your syntax.  On the other hand, we may well
> want a sizeof operator in dtc itself as part of our expression
> support, and in that case, the "be like C" principle suggests it
> should be rendered as "sizeof" rather than "/sizeof/".
> 
> But as I said that can be dealt with in the future without breaking
> compatibility.  Objection withdrawn.

Hi,

To add one more point to the discussion: the /incbin/ syntax is being
used in the new image format of U-Boot (we're using dtc with original
patch by Scott Wood, i.e.,
http://www.nabble.com/-PATCH--Add-support-for-binary-includes.-td15596760.html).

If possible, it would be good to have the original syntax preserved once
the feature is merged into the mainline dtc. BTW: any idea on when this
might happen?

Regards,
Bartlomiej

  reply	other threads:[~2008-06-04 13:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-20 19:19 [PATCH] Add support for binary includes Scott Wood
2008-02-22  5:34 ` David Gibson
2008-02-22 18:12   ` Jon Loeliger
2008-02-25  3:38     ` David Gibson
2008-02-22  6:05 ` Grant Likely
2008-02-22  8:34   ` Bartlomiej Sieka
2008-02-22  9:02   ` David Woodhouse
2008-02-22 15:50     ` Grant Likely
2008-02-22 16:08   ` Scott Wood
2008-02-22 16:24     ` Jon Loeliger
2008-02-22 16:28       ` Scott Wood
2008-02-26  0:39 ` David Gibson
2008-02-26 17:26   ` Scott Wood
2008-05-27 15:27   ` Kumar Gala
2008-05-27 17:59     ` Jon Loeliger
2008-05-28 23:58       ` David Gibson
2008-05-29  0:02         ` David Gibson
2008-05-30 18:54           ` Scott Wood
2008-06-04  4:13             ` David Gibson
2008-06-04 12:36               ` Bartlomiej Sieka [this message]
2008-06-04 14:26               ` Jon Loeliger
2008-06-05  3:11                 ` Josh Boyer
2008-06-11  1:58                 ` dtc: " David Gibson
2008-06-12 16:43                   ` Scott Wood
2008-06-13  0:01                     ` David Gibson
2008-06-13  0:46                       ` Jon Loeliger
2008-06-13  3:41                         ` David Gibson
2008-05-29 14:04         ` [PATCH] " Jon Loeliger
2008-05-30  1:34           ` David Gibson
2008-06-02 20:22             ` Jon Loeliger

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48468C5A.6030504@semihalf.com \
    --to=tur@semihalf$(echo .)com \
    --cc=galak@kernel$(echo .)crashing.org \
    --cc=jdl@freescale$(echo .)com \
    --cc=jdl@jdl$(echo .)com \
    --cc=linuxppc-dev@ozlabs$(echo .)org \
    --cc=scottwood@freescale$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox