public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed

From: Jon Loeliger <jdl@jdl•com>
To: David Gibson <david@gibson•dropbear.id.au>
Cc: linuxppc-dev@ozlabs•org
Subject: Re: [PATCH] DTC: Polish up the DTS Version 1 implementation.
Date: Fri, 09 Nov 2007 08:32:57 -0600	[thread overview]
Message-ID: <E1IqUun-00063a-7g@jdl.com> (raw)
In-Reply-To: Your message of "Fri, 09 Nov 2007 11:13:45 +1100." <20071109001345.GD18592@localhost.localdomain>

So, like, the other day David Gibson mumbled:
> 
> But you do take a hit w.r.t. *minimum* representation size - there's
> no form amongst all the possibilities here more compact than pure hex.
> Especially since spaces are optional in the old form.  The fact that
> [ab cd 00] and [abcd00] are equivalent was a deliberate choice in the
> original form.
> 
> The point of [] is for random binary data which is neither strings
> (even with the odd strange character) nor sensibly organized into
> 32-bit (or larger) integers.  Wanting something other than hex here is
> much rarer than in the < > case.
> 
> You're seeing < > and [ ] as basically the same thing - a list of
> values - with the only difference being the size of those values.
> That's not wrong, but it's not the only way to look at it - and it's
> not the way I was thinking of [ ] when I invented it.  Your proposal
> makes perfect sense while you think of [] as a list of values - but
> not so much when it's thought of as a direct binary representation.
> 
> So I'm thinking perhaps we need two different things here: a "list of
> values" representation, which can accomodate expressions and can also
> have multiple sizes (because expressions which are evaluated to a
> 16-bit or 64-bit value could also be useful under the right
> circumstances), and the [ ] "bytestring
> literal" representation.  Perhaps something like:
> 
> (32-bit values)
> 	<0xdeadbeef (1+1)>
> or	<.32 0xdeadbeef (1+1)>
> 
> (64-bit values)
> 	<.64 (0xdeadbeef << 32) (-1)>
> (8-bit values)
> 	<.8 0x00 0x0a 0xe4 0x2c 0x23 (0x10 + n)>
> 
> i.e. < > is list of values form, with size of each value as a sort of
> parameter (defaulting to 32-bit, of course).  I'm not sure I like that
> particular syntax, it's just the first thing I came up with to
> demonstrate the idea.


Ah ha!  I see.  You want this, then:

    x = <.srec 0000 C001C0DEGE75BABE F1>

OK.  That was entirely joking.  We all know that
the cool code does NOT get the babe.

Seriously though, I see your point, and I don't really
have a strong opinion here, so in the interest of making
some headway, we can just leave it as is for now.

If it turns out to be a bad decision later, we'll fix it. :-)

And with that issue behind us....

I'm going to post these patches to introduce the new DTS format!
Any last straggler comments?

Thanks,
jdl

next prev parent reply	other threads:[~2007-11-09 14:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-06 22:19 [PATCH] DTC: Polish up the DTS Version 1 implementation Jon Loeliger
2007-11-06 23:11 ` David Gibson
2007-11-07 14:14   ` Jon Loeliger
2007-11-07 23:19     ` David Gibson
2007-11-08 14:13       ` Jon Loeliger
2007-11-09  0:13         ` David Gibson
2007-11-09 14:32           ` Jon Loeliger [this message]
2007-11-12  3:04             ` David Gibson
2007-11-08 19:18     ` DTS Bytestrings Representation in /dts-v1/ files Jon Loeliger
2007-11-08 19:33       ` Josh Boyer
2007-11-09  0:21       ` David Gibson

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=E1IqUun-00063a-7g@jdl.com \
    --to=jdl@jdl$(echo .)com \
    --cc=david@gibson$(echo .)dropbear.id.au \
    --cc=linuxppc-dev@ozlabs$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox