On Thu, 2017-06-15 at 07:30 -0500, Rob Herring wrote:
> On Wed, Jun 14, 2017 at 3:56 PM, Joe Perches <joe@xxxxxxxxxxx> wrote:
> > On Wed, 2017-06-14 at 15:30 -0500, Rob Herring wrote:
> > > From: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx>
> >
> > I think the commit subject is wrong.
> > It adds an "of" specific bit to vsprintf.c.
> > The subject should be
> > 'vsprintf: Add %p extension "%pO" for device tree'
>
> Okay, but it was good enough for the 2-3 versions Pantelis did before...
Which were not applied.
> > > 90% of the usage of device node's full_name is printing it out
> > > in a kernel message. Preparing for the eventual delayed allocation
The "eventual delayed allocation" bit doesn't
mean anything to me.
> > > introduce a custom printk format specifier that is both more
> > > compact and more pleasant to the eye.
> > >
> > > For instance typical use is:
> > > pr_info("Frobbing node %s\n", node->full_name);
> > >
> > > Which can be written now as:
> > > pr_info("Frobbing node %pOF\n", node);
> >
> > Somehow I think this example is poor as node->full_name
> > is a pretty obvious to read use. %pOF requires you to
> > look up or know what the output is going to be.
>
> So %pOFfullname? We've beat this one to death IMO.
I don't doubt the utility, just the example.
Just mention that full_name is going away.
> > > More fine-grained control of formatting includes printing the name,
> > > flag, path-spec name, reference count and others, explained in the
> > > documentation entry.
> > >
> > > Originally written by Pantelis, but pretty much rewrote the core
> > > function using existing string/number functions. The 2 passes were
> > > unnecessary and have been removed. Also, updated the checkpatch.pl
> > > check.
> >
> > Some comments about the code.
> >
> > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > > []
> > > @@ -1470,6 +1471,123 @@ char *flags_string(char *buf, char *end, void *flags_ptr, const char *fmt)
> > > return format_flags(buf, end, flags, names);
> > > }
> > >
> > > +static noinline_for_stack
> > > +char *device_node_gen_full_name(const struct device_node *np, char *buf, char *end)
> > > +{
> > > + int len, ret;
> > > +
> > > + if (!np || !np->parent)
> > > + return buf;
> > > +
> > > + buf = device_node_gen_full_name(np->parent, buf, end);
> >
> > This is recursive. How many levels of parents could there be?
> > Perhaps there should be a recursion limit.
>
> 2-6 I'd say is typical. The FDT unflattening code limits things to 64
> (which is probably way more than needed).
>
> I could re-write it to be non-recursive, but then I'll just have the
> max sized array of pointers on the stack.
Which would be less stack than how many recursive calls? 5?
In any case, 64 * 8 for pointers or 5+ stack
frames is a fair amount of stack.
Maybe too much.
> > > + case 'F': /* flags */
> > > + snprintf(tbuf, sizeof(tbuf), "%c%c%c%c",
> > > + of_node_check_flag(dn, OF_DYNAMIC) ?
> > > + 'D' : '-',
> > > + of_node_check_flag(dn, OF_DETACHED) ?
> > > + 'd' : '-',
> > > + of_node_check_flag(dn, OF_POPULATED) ?
> > > + 'P' : '-',
> > > + of_node_check_flag(dn,
> > > + OF_POPULATED_BUS) ? 'B' : '-');
> >
> > I'd try to avoid all uses of snprintf as it's effectively
> > another fairly large stack frame.
>
> Okay.
>
> > It's probably better to avoid more recursion stack depth use
> > and just use *buf++ as appropriate.
>
> You can't use *buf++ as this code must work and increment buf even
> when buf is NULL.
tbuf then.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
