[PATCH] libfdt.h: Define FDT_PATH_MAX

[PATCH] libfdt.h: Define FDT_PATH_MAX

[Pantelis Antoniou]

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>
---
 libfdt/libfdt.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
index a248b1b..a5c93f6 100644
--- a/libfdt/libfdt.h
+++ b/libfdt/libfdt.h
@@ -139,6 +139,9 @@
 
 #define FDT_ERR_MAX		17
 
+/* Maximum path size of a node (similar to PATH_MAX in *nix) */
+#define FDT_PATH_MAX	4096
+
 /**********************************************************************/
 /* Low-level functions (you probably don't need these)                */
 /**********************************************************************/
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] libfdt.h: Define FDT_PATH_MAX

[David Gibson]

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

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.

> ---
>  libfdt/libfdt.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
> index a248b1b..a5c93f6 100644
> --- a/libfdt/libfdt.h
> +++ b/libfdt/libfdt.h
> @@ -139,6 +139,9 @@
>  
>  #define FDT_ERR_MAX		17
>  
> +/* Maximum path size of a node (similar to PATH_MAX in *nix) */
> +#define FDT_PATH_MAX	4096
> +
>  /**********************************************************************/
>  /* Low-level functions (you probably don't need these)                */
>  /**********************************************************************/

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

Re: [PATCH] libfdt.h: Define FDT_PATH_MAX

[Pantelis Antoniou]

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.

Regards

-- Pantelis

> > ---
> >  libfdt/libfdt.h | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
> > index a248b1b..a5c93f6 100644
> > --- a/libfdt/libfdt.h
> > +++ b/libfdt/libfdt.h
> > @@ -139,6 +139,9 @@
> >  
> >  #define FDT_ERR_MAX		17
> >  
> > +/* Maximum path size of a node (similar to PATH_MAX in *nix) */
> > +#define FDT_PATH_MAX	4096
> > +
> >  /**********************************************************************/
> >  /* Low-level functions (you probably don't need these)                */
> >  /**********************************************************************/
> 

Re: [PATCH] libfdt.h: Define FDT_PATH_MAX

[David Gibson]

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

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

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

Re: [PATCH] libfdt.h: Define FDT_PATH_MAX

[Tom Rini]

[-- 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 --]

Re: [PATCH] libfdt.h: Define FDT_PATH_MAX

[David Gibson]

[-- 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 --]