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@xxxxxxxxxxxx> > > > > > > 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:
signature.asc
Description: Digital signature
