All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: "Joe Perches" <joe@perches.com>, "Petr Mladek" <pmladek@suse.com>,
	"Uwe Kleine-König" <uwe@kleine-koenig.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Jonathan Corbet" <corbet@lwn.net>
Subject: Re: [PATCH v4 0/1] printf: add support for printing symbolic error names
Date: Tue, 26 Nov 2019 15:04:06 +0100	[thread overview]
Message-ID: <CAMuHMdXSt_xtgUz+r9n5_YkJU09HUttbfibOvw8b2zBdXZtT4g@mail.gmail.com> (raw)
In-Reply-To: <20191011133617.9963-1-linux@rasmusvillemoes.dk>

Hi Rasmus,

Nice idea!

On Fri, Oct 11, 2019 at 3:38 PM Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> This is a bit much for under the ---, so a separate cover letter for
> this single patch.
>
> v4: Dropped Uwe's ack since it's changed quite a bit. Change
> errcode->errname as suggested by Petr. Make it 'default y if PRINTK'
> so it's available in the common case, while those who have gone to
> great lengths to shave their kernel to the bare minimum are not
> affected.
>
> Also require the caller to use %pe instead of printing all ERR_PTRs
> symbolically. I can see some value in having the call site explicitly
> indicate that they're printing an ERR_PTR (i.e., having the %pe), but
> I also still believe it would make sense to print ordinary %p,
> ERR_PTR() symbolically instead of as a random hash value that's not
> stable across reboots. But in the interest of getting this in, I'll
> leave that for now. It's easy enough to do later by just changing the
> "case 'e'" to do a break (with an updated comment), then do an
> IS_ERR() check after the switch.
>
> Something I've glossed over in previous versions, and nobody has
> commented on, is that I produced "ENOSPC" while the 'fallback' would
> print "-28" (i.e., there's no minus in the symbolic case). I don't
> care much either way, but here I've tried to show how I'd do it if we
> want the minus also in the symbolic case. At first, I tried just using
> the standard idiom
>
>   if (buf < end)
>     *buf = '-';
>   buf++;
>
> followed by string(sym, ...). However, that doesn't work very well if
> one wants to honour field width - for that to work, the whole string
> including - must come from the errname() lookup and be handled by
> string(). The simplest seemed to be to just unconditionally prefix all
> strings with "-" when building the tables, and then change errname()
> back to supporting both positive and negative error numbers.

Still, it looks a bit wasteful to me to include the dash in each and every
string value.

Do you think you can code the +/- logic in string_nocheck() in less than
the gain achieved by dropping the dashes from the tables?
(e.g. by using the SIGN spec.flags? ;-)
Or, do we need it? IS_ERR() doesn't consider positive values errors.

Oh, what about the leading "E"? That one looks harder to get rid of,
though ;-)

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  parent reply	other threads:[~2019-11-26 14:04 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-30 21:46 [PATCH] printf: add support for printing symbolic error codes Rasmus Villemoes
2019-08-30 21:53 ` Joe Perches
2019-08-30 22:03   ` Rasmus Villemoes
2019-08-30 22:21     ` Joe Perches
2019-08-30 22:50       ` Rasmus Villemoes
2019-09-02  9:07         ` David Laight
2019-08-31  9:38 ` kbuild test robot
2019-09-02 15:29 ` Uwe Kleine-König
2019-09-04  9:13   ` Rasmus Villemoes
2019-09-04  9:21     ` Uwe Kleine-König
2019-09-04 16:19 ` Andy Shevchenko
2019-09-04 16:28   ` Uwe Kleine-König
2019-09-05 11:40     ` Rasmus Villemoes
2019-09-09 20:38 ` [PATCH v2] " Rasmus Villemoes
2019-09-10 15:26   ` Andy Shevchenko
2019-09-11  0:15     ` Joe Perches
2019-09-11  6:43       ` Rasmus Villemoes
2019-09-11  9:37         ` Uwe Kleine-König
2019-09-11 10:14           ` Rasmus Villemoes
2019-09-15  9:43   ` Pavel Machek
2019-09-16 12:23   ` Uwe Kleine-König
2019-09-16 13:23     ` Rasmus Villemoes
2019-09-16 13:36       ` Uwe Kleine-König
2019-09-17  6:59   ` [PATCH v3] " Rasmus Villemoes
2019-09-25 14:36     ` Petr Mladek
2019-09-29 20:09       ` Rasmus Villemoes
2019-10-02  8:34         ` Petr Mladek
2019-10-05 21:48     ` Andrew Morton
2019-10-11 13:36     ` [PATCH v4 0/1] printf: add support for printing symbolic error names Rasmus Villemoes
2019-10-11 13:36       ` [PATCH v4 1/1] " Rasmus Villemoes
2019-10-14  5:51         ` Uwe Kleine-König
2019-10-14 13:02         ` Petr Mladek
2019-10-14 13:10           ` Andy Shevchenko
2019-10-15 12:17           ` Rasmus Villemoes
2019-10-15 13:44           ` David Laight
2019-10-15 19:07       ` [PATCH v5] " Rasmus Villemoes
2019-10-16 13:49         ` Andy Shevchenko
2019-10-16 14:52           ` Petr Mladek
2019-10-16 16:31             ` Andy Shevchenko
2019-10-17 15:02               ` Petr Mladek
2019-11-26 14:04       ` Geert Uytterhoeven [this message]
2019-11-27  8:54         ` [PATCH v4 0/1] " Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMuHMdXSt_xtgUz+r9n5_YkJU09HUttbfibOvw8b2zBdXZtT4g@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=akpm@linux-foundation.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=corbet@lwn.net \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=pmladek@suse.com \
    --cc=uwe@kleine-koenig.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.