On Thu, Jul 16, 2015 at 10:56:23AM -0600, Simon Glass wrote: > Hi David, > > On 15 July 2015 at 23:27, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Jul 15, 2015 at 03:45:07PM -0600, Simon Glass wrote: > >> Hi Jon, > >> > >> On 15 July 2015 at 07:29, Jon Loeliger <jdl@xxxxxxx> wrote: > >> > > >> > So, like, Thierry Reding said: > >> > > From: Thierry Reding <treding@xxxxxxxxxx> > >> > > > >> > > These three patches add a couple of string functions that have proven > >> > > useful in U-Boot's copy of libfdt, so they are likely to be useful for > >> > > other users as well. > >> > > > >> > > Patch 1 adds a function to count the number of strings in a property's > >> > > value. This also adds a new DTS sample along with a small test program > >> > > to validate the implemented functions. > >> > > > >> > > Patch 2 adds a function to retrieve the index of a given string in any > >> > > given property's value. This adds code to the test program introduced in > >> > > the previous patch to exercise the new functionality. > >> > > > >> > > Patch 3 adds a function to retrieve a string by index from a property's > >> > > value along with a shortcut for index 0. This extends the test program > >> > > introduced in patch 1 to validate the new functionality. > >> > > > >> > > Thierry > >> > > >> > > >> > Hi Thierry, > >> > > >> > While I am generally fine with this patch set, I have > >> > a large-scope question. Is there a larger plan to > >> > consolidate or unify the U-Boot and DTC libfdts? > >> > >> I maintain the fdt tree for U-Boot at present. About once a quarter I > >> check what has changed and do a bit of a sync. But there are things > >> that libfdt upstream has not accepted - e.g. the grep functionality > >> used by verified boot hashing stuff. I wish we could figure that out. > >> Perhaps a cut-down fdtgrep tool would meet with favour. We're using it > >> even more now since SPL (the minimal U-Boot loader) wants to run with > >> a subset of the full board FDT for SRAM space reasons. > > > > So, short-term: there's no reason your fdtgrep stuff needs to be > > considered as part of your version of libfdt - it could just as easily > > be an add-on sitting alongside libfdt - then you could share the core > > libfdt code at least. > > That's how it is today, yes. > > > > > Longer term, my main sticking point on the fdtgrep stuff was entry > > points whose semantics don't make me go cross-eyed (includes these > > nodes, but not those nodes, and might include children if this flag is > > set, but not that one and the operator's shoe size matches some other > > property...). I'm not sure if that's a question of redesigning the > > interface, or just of describing it better. > > Neither am I, but perhaps if I cut down the fdtgrep options so that it > only does a few basic things that would help? The full feature set > would still be in the implementation, but it would reduce confusion on > that side. It's not really the fdtgrep tool which bothers me, I'm much more concerned with the semantics of the libfdt function it uses to do its work. > >> I do ask people to send things upstream, and if rejected we then have > >> to work out what to do...there are recent U-Boot mailing list threads > >> on this. > >> > >> Regards, > >> Simon > > > > Regards, > Simon -- 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
Attachment:
pgplpCdSY3lRQ.pgp
Description: PGP signature
