Hi David, On Sun, 6 Feb 2022 at 21:10, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > 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. It is sufficient to achieve its purpose, but I don't think it is any more complex than that. > > 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. Are you suggesting: 1. that libfdt should move to a new maintainer 2. that you would accept these patches if someone else maintained them within the libfdt tree 3. that we set up a separate tree to fork libfdt, with these changes in 4. that we put these changes in a separate tree? Regards, Simon
