Re: [PATCH] libfdt.h: Define FDT_PATH_MAX

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

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

On Mon, Jul 10, 2017 at 07:36:16AM -0400, Tom Rini wrote:
> On Mon, Jul 10, 2017 at 02:43:58PM +1000, David Gibson wrote:
> > On Wed, Jun 14, 2017 at 10:24:01PM +0300, Pantelis Antoniou wrote:
> > > Hi David,
> > > 
> > > On Wed, 2017-06-14 at 23:05 +0800, David Gibson wrote:
> > > > On Wed, Jun 14, 2017 at 05:51:48PM +0300, Pantelis Antoniou wrote:
> > > > > Declare the maximum path size of an FDT node.
> > > > > It is useful for manipulation methods that need to know a maximum value.
> > > > > 
> > > > > Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> > > > 
> > > > Why do you need this.  I've really tried to avoid adding arbitrary
> > > > size limits on things.
> > > > 
> > > 
> > > The stacked overlay patch needs it; has to 'read' in a path into a
> > > buffer and manipulate it. Otherwise it I would have to add a new method
> > > that walks the path and returns the size of it so that I can allocate
> > > the exact amount. This seems excessive IMO compared to a hard max limit.
> > > 
> > > It is similar to the way PATH_MAX works in *nix which makes things
> > > somewhat familiar.
> > 
> > This is not necessary.  As noted elsewhere, I'm not really convinced
> > of the need of the stacked overlay application patch at all.
> 
> How would you suggest handling the case of N baseboards and M add-on
> boards?  Creating a single overlay for each of the valid combinations of
> M is very unappealing and is one of those long-term support nightmares
> (change out the LCD panel part? Time to re-create those M combinations
> again).

Sorry, I wasn't clear.   Obviously being able to stack overlays is
useful.

What I'm not convinced of is that we need to change the overlay
application logic, rather than just the overlay generation to
accomplish that.

> > But even
> > if we took that approach I can see fairly straightforward ways to
> > eliminate the need for a PATH_MAX (removing the arbitrary limit with
> > it).
> 
> Can you suggest some of those approaches so we can try them out then?
> Thanks!

I'm disinclined to comment in depth on the current series, until I see
a reason that it's actually a better approach than the compile time
only change I'm suggested.

In short, though, you can use fdt_subnode_offset_namelen() and
fdt_appendprop() in order to do the __symbols__ merging without
needing to explicitly construct the resolved path in a temporary
buffer.  That avoids the need for an arbitrary PATH_MAX limit, as well
as the malloc(), which libfdt isn't supposed to be using anyway.

-- 
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: 819 bytes --]