Re: [PATCH] libfdt.h: Define FDT_PATH_MAX

[Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>]

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

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).

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

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]