| Message ID | 20210428135929.27011-2-justin.he@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
On Wed 2021-04-28 21:59:27, Jia He wrote: > From: Linus Torvalds <torvalds@linux-foundation.org> > > We have '%pD'(no digit following) for printing a filename. It may not be > perfect (by default it only prints one component. > > %pD4 should be more than good enough, but we should make plain "%pD" mean > "as much of the path that is reasonable" rather than "as few components as > possible" (ie 1). Could you please provide link to the discussion where this idea was came from? It would be great to add and example into the commit message how it improved the output. Also please explain why it is useful/safe to change the behavior for all existing users. It seems that you checked them and prevented any regression by the other patches in this patchset. Anyway, some regressions are fixed by the followup patches. It would break bisection. We either need to prevent the regression before this patch. Or the changes have to be done in this patch. For example, it would be perfectly fine to update test_printf.c in this patch. > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> If you want to keep Linus as the author and do more changes, you might describe here changes done by you, for example: [justin.he@arm.com: update documentation and test_printf] Signed-off-by: Jia He <justin.he@arm.com> Or you might make you the author and add Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> > --- > Documentation/core-api/printk-formats.rst | 3 ++- > lib/vsprintf.c | 4 ++-- > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst > index 9be6de402cb9..aa76cbec0dae 100644 > --- a/Documentation/core-api/printk-formats.rst > +++ b/Documentation/core-api/printk-formats.rst Plese, update also the pattern: - %pd{,2,3,4} - %pD{,2,3,4} + %pd{1,2,3,4} + %pD{1,2,3,4} > @@ -413,7 +413,8 @@ dentry names > For printing dentry name; if we race with :c:func:`d_move`, the name might > be a mix of old and new ones, but it won't oops. %pd dentry is a safer > equivalent of %s dentry->d_name.name we used to use, %pd<n> prints ``n`` > -last components. %pD does the same thing for struct file. > +last components. %pD does the same thing for struct file. By default, %p{D,d} > +is equal to %p{D,d}4. > > Passed by reference. Best Regards, Petr
On Thu, Apr 29, 2021 at 11:47 AM Petr Mladek <pmladek@suse.com> wrote: > > On Wed 2021-04-28 21:59:27, Jia He wrote: > > From: Linus Torvalds <torvalds@linux-foundation.org> > > > > We have '%pD'(no digit following) for printing a filename. It may not be > > perfect (by default it only prints one component. > > > > %pD4 should be more than good enough, but we should make plain "%pD" mean > > "as much of the path that is reasonable" rather than "as few components as > > possible" (ie 1). > > Could you please provide link to the discussion where this idea was > came from? https://lore.kernel.org/lkml/20210427025805.GD3122264@magnolia/ -- With Best Regards, Andy Shevchenko
On Thu 2021-04-29 11:52:49, Andy Shevchenko wrote: > On Thu, Apr 29, 2021 at 11:47 AM Petr Mladek <pmladek@suse.com> wrote: > > > > On Wed 2021-04-28 21:59:27, Jia He wrote: > > > From: Linus Torvalds <torvalds@linux-foundation.org> > > > > > > We have '%pD'(no digit following) for printing a filename. It may not be > > > perfect (by default it only prints one component. > > > > > > %pD4 should be more than good enough, but we should make plain "%pD" mean > > > "as much of the path that is reasonable" rather than "as few components as > > > possible" (ie 1). > > > > Could you please provide link to the discussion where this idea was > > came from? > > https://lore.kernel.org/lkml/20210427025805.GD3122264@magnolia/ Thanks for the link. I see that it was not clear whether the patch was good for %pd behavior. Linus actually suggests to keep %pd behavior as it was before, see https://lore.kernel.org/lkml/CAHk-=wimsMqGdzik187YWLb-ru+iktb4MYbMQG1rnZ81dXYFVg@mail.gmail.com/ Well, I think that this is up to the file system developers to decide. I am not sure if the path would do more harm than good, or vice versa, for dentry names. Best Regards, Petr
Hi > -----Original Message----- > From: Petr Mladek <pmladek@suse.com> > Sent: Thursday, April 29, 2021 5:25 PM > To: Andy Shevchenko <andy.shevchenko@gmail.com> > Cc: Justin He <Justin.He@arm.com>; Linus Torvalds <torvalds@linux- > foundation.org>; Steven Rostedt <rostedt@goodmis.org>; Sergey Senozhatsky > <senozhatsky@chromium.org>; Andy Shevchenko > <andriy.shevchenko@linux.intel.com>; Rasmus Villemoes > <linux@rasmusvillemoes.dk>; Jonathan Corbet <corbet@lwn.net>; Luca Coelho > <luciano.coelho@intel.com>; Kalle Valo <kvalo@codeaurora.org>; David S. > Miller <davem@davemloft.net>; Jakub Kicinski <kuba@kernel.org>; Heiko > Carstens <hca@linux.ibm.com>; Vasily Gorbik <gor@linux.ibm.com>; Christian > Borntraeger <borntraeger@de.ibm.com>; Johannes Berg > <johannes.berg@intel.com>; Linux Documentation List <linux- > doc@vger.kernel.org>; Linux Kernel Mailing List <linux- > kernel@vger.kernel.org>; open list:TI WILINK WIRELES... <linux- > wireless@vger.kernel.org>; netdev <netdev@vger.kernel.org>; linux- > s390@vger.kernel.org > Subject: Re: [PATCH 2/4] lib/vsprintf.c: Make %p{D,d} mean as much > components as possible > > On Thu 2021-04-29 11:52:49, Andy Shevchenko wrote: > > On Thu, Apr 29, 2021 at 11:47 AM Petr Mladek <pmladek@suse.com> wrote: > > > > > > On Wed 2021-04-28 21:59:27, Jia He wrote: > > > > From: Linus Torvalds <torvalds@linux-foundation.org> > > > > > > > > We have '%pD'(no digit following) for printing a filename. It may not > be > > > > perfect (by default it only prints one component. > > > > > > > > %pD4 should be more than good enough, but we should make plain "%pD" > mean > > > > "as much of the path that is reasonable" rather than "as few > components as > > > > possible" (ie 1). > > > > > > Could you please provide link to the discussion where this idea was > > > came from? > > > > https://lore.kernel.org/lkml/20210427025805.GD3122264@magnolia/ > > Thanks for the link. I see that it was not clear whether the patch > was good for %pd behavior. > > Linus actually suggests to keep %pd behavior as it was before, see > https://lore.kernel.org/lkml/CAHk-=wimsMqGdzik187YWLb- > ru+iktb4MYbMQG1rnZ81dXYFVg@mail.gmail.com/ Okay, let me keep the default %pd behavior as before('%pd' is '%pd1') and change the behavior of %pD ('%pD' is '%pD4') -- Cheers, Justin (Jia He) > > Well, I think that this is up to the file system developers to decide. > I am not sure if the path would do more harm than good, > or vice versa, for dentry names. > > Best Regards, > Petr IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index 9be6de402cb9..aa76cbec0dae 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -413,7 +413,8 @@ dentry names For printing dentry name; if we race with :c:func:`d_move`, the name might be a mix of old and new ones, but it won't oops. %pd dentry is a safer equivalent of %s dentry->d_name.name we used to use, %pd<n> prints ``n`` -last components. %pD does the same thing for struct file. +last components. %pD does the same thing for struct file. By default, %p{D,d} +is equal to %p{D,d}4. Passed by reference. diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 6c56c62fd9a5..5b563953f970 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -880,11 +880,11 @@ char *dentry_name(char *buf, char *end, const struct dentry *d, struct printf_sp int i, n; switch (fmt[1]) { - case '2': case '3': case '4': + case '1': case '2': case '3': case '4': depth = fmt[1] - '0'; break; default: - depth = 1; + depth = 4; } rcu_read_lock();