Devicetree
 help / color / mirror / Atom feed
* libfdt: Property iteration
@ 2008-10-27 22:14 Scott Wood
       [not found] ` <20081027221441.GA8763-VKaLA/mbEU932VTgPCOETVjVikpgYyvb5NbjCUgZEJk@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Scott Wood @ 2008-10-27 22:14 UTC (permalink / raw)
  To: David Gibson; +Cc: devicetree-discuss-mnsaURCQ41sdnm+yROfE0A

A while back when discussing property iterators
(http://ozlabs.org/pipermail/linuxppc-dev/2008-January/049891.html), you
said that you'd prefer not to expose property offsets, because more
common uses would be affected by changing offsets.  I'm looking again at
this, and was wondering what alternative and would-be-broken use cases
you were thinking of?

We could operate on property indices or names at an efficiency cost. 
Most nodes should be small enough that the cost isn't too much, but I'd
like to know which use cases really need it.  The ones I'd use it for
involve reading from one tree and adding to another, so moving offsets
aren't an issue.

Even in a use case where one makes in-place changes while iterating over
properties, changes to the property currently being iterated over should
only move later properties -- the next call to fdt_next_prop would be
based on the start of the property that was modified, which did not
change.

-Scott

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-11-07  3:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-27 22:14 libfdt: Property iteration Scott Wood
     [not found] ` <20081027221441.GA8763-VKaLA/mbEU932VTgPCOETVjVikpgYyvb5NbjCUgZEJk@public.gmane.org>
2008-11-07  2:54   ` David Gibson
     [not found]     ` <20081107025444.GK6692-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>
2008-11-07  3:39       ` David Gibson

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