Re: [PATCH v4 0/4] Introduce fdtgrep for subsetting and hashing FDTs

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

On Tue, Feb 08, 2022 at 02:43:44PM -0700, Simon Glass wrote:
> Hi David,
> 
> On Sun, 6 Feb 2022 at 21:10, David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> 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.

I don't disagree, but that still ends up being quite complex.

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

Right now (4) is what I'm suggesting.  Or to be more precise, creating
a new repo with "libfdtrange" or whatever, that depends on libfdt.

(1) and/or (2) are potentially worthy of further discussion.  (3) is
just a bad idea, IMO.

-- 
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]