All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Jon Loeliger <jdl@jdl.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] DTC: Polish up the DTS Version 1 implementation.
Date: Mon, 12 Nov 2007 14:04:02 +1100	[thread overview]
Message-ID: <20071112030402.GA1404@localhost.localdomain> (raw)
In-Reply-To: <E1IqUun-00063a-7g@jdl.com>

On Fri, Nov 09, 2007 at 08:32:57AM -0600, Jon Loeliger wrote:
> 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.

Hrm.. I think I'm not getting all the allusions here.

> 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. :-)

Works for me.  And we even have some ideas on how to fix it, if we
have to, without too much horror, so that seems like a reasonable
position to me.

> And with that issue behind us....
> 
> I'm going to post these patches to introduce the new DTS format!
> Any last straggler comments?

Hurrah.  Let's do it!

-- 
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

  reply	other threads:[~2007-11-12  3:04 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
2007-11-12  3:04             ` David Gibson [this message]
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=20071112030402.GA1404@localhost.localdomain \
    --to=david@gibson.dropbear.id.au \
    --cc=jdl@jdl.com \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.