On Sun, Nov 07, 2021 at 03:43:42PM -0700, Simon Glass wrote: > Note: This was last sent 6 years ago. It really belongs upstream and I > believe it is useful functionality for libfdt, so I am trying again. > Please take a fresh look at this. It is cut back from the previous series. > If accepted we can expand the feature set piece by piece from here. Sorry it's taken me so long to look at this. Again. I can't dispute that it's useful for certain use cases. But as for belonging upstream... This series adds quite a lot of conceptual complexity. It introduces a new data structure, new state structures, a entirely new mode of working with a tree and a bunch of configuration parameter types on top of the new entry points and new tool. I still find the semantics of the different criteria for inclusion/exclusion from a region pretty bewildering. That makes me pretty disinclined to add this to the scope of maintenance for libfdt. As you've probably noticed, I'm already struggling to keep on top of maintenance for the existing libfdt interfaces. AFAICT everything here can be implemented fairly naturally in terms of libfdt's existing public interface. so I'm not really seeing a compelling reason for this to be merged into libfdt, rather than being its own separate library that depends on libfdt. -- 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:
signature.asc
Description: PGP signature
