devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: [PATCH] dtc: Add ability to delete nodes and properties
Date: Wed, 21 Mar 2012 17:13:40 +1100	[thread overview]
Message-ID: <20120321061340.GE15997@truffala.fritz.box> (raw)
In-Reply-To: <4F68C677.7070501-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>

On Tue, Mar 20, 2012 at 12:03:35PM -0600, Stephen Warren wrote:
> On 03/13/2012 04:48 PM, Stephen Warren wrote:
> > dtc currently allows the contents of properties to be changed, and the
> > contents of nodes to be added to. There are situations where removing
> > properties or nodes may be useful. This change implements the following
> > syntax to do that:
> > 
> >     / {
> >         propname /delprop/;
> >         nodename /delnode/;
> >     };
> > 
> > or:
> > 
> >     &noderef /delnode/;
> 
> Jon, David, any thoughts on this?

Hrm, some, but not terribly clear ones.

So, superficially, your patch looks fine, making the obvious
straightforward implementation of deletion.  I'm about 85% convinced
the syntax for it is as good as we can reasonably get.

Unfortunately the obvious deletion implementation raises some issues
with labels.  With this patch, for the first time ever, it's possible
to delete labels (along with the node or property they're attached
to).  And further, having deleted a labelled node or property a new
one could created using the same label.

Our label semantics have been worked out with the assumption that
labels are immutable, so the order of anything to do with them doesn't
matter.  Now, if a label is attached, removed then reassigned,
references to that label could resolve differently depending on the
not-obvious-to-the-user internal order of processing.

I think the sanest way to resolve this from the user visible point of
view is to keep the assumption that labels are always fixed.  That
means that even if a labelled node is removed, the label cannot be
reused.  Attempting to re-use the label will give an error as will
referencing the label (from anywhere that's not itself deleted).

But implementing that means doing a rework on how we store labels /
nodes / properties and manage their lifetimes.  It's not a huge body
of work, but it's not completely trivial either.

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

      parent reply	other threads:[~2012-03-21  6:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-13 22:48 [PATCH] dtc: Add ability to delete nodes and properties Stephen Warren
     [not found] ` <1331678894-31251-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-03-20 18:03   ` Stephen Warren
     [not found]     ` <4F68C677.7070501-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-03-21  6:13       ` David Gibson [this message]

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=20120321061340.GE15997@truffala.fritz.box \
    --to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).