[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20191005144830.f94bc9d63001981c5eefe875@linux-foundation.org>
Date: Sat, 5 Oct 2019 14:48:30 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Jonathan Corbet <corbet@....net>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Joe Perches <joe@...ches.com>, Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Uwe Kleine-König <uwe@...ine-koenig.org>,
linux-doc@...r.kernel.org, Pavel Machek <pavel@....cz>
Subject: Re: [PATCH v3] printf: add support for printing symbolic error
codes
On Tue, 17 Sep 2019 08:59:59 +0200 Rasmus Villemoes <linux@...musvillemoes.dk> wrote:
> It has been suggested several times to extend vsnprintf() to be able
> to convert the numeric value of ENOSPC to print "ENOSPC". This is yet
> another attempt. Rather than adding another %p extension, simply teach
> plain %p to convert ERR_PTRs. While the primary use case is
>
> if (IS_ERR(foo)) {
> pr_err("Sorry, can't do that: %p\n", foo);
> return PTR_ERR(foo);
> }
>
> it is also more helpful to get a symbolic error code (or, worst case,
> a decimal number) in case an ERR_PTR is accidentally passed to some
> %p<something>, rather than the (efault) that check_pointer() would
> result in.
>
> With my embedded hat on, I've made it possible to remove this.
>
> I've tested that the #ifdeffery in errcode.c is sufficient to make
> this compile on arm, arm64, mips, powerpc, s390, x86 - I'm sure the
> 0day bot will tell me which ones I've missed.
>
> The symbols to include have been found by massaging the output of
>
> find arch include -iname 'errno*.h' | xargs grep -E 'define\s*E'
>
> In the cases where some common aliasing exists
> (e.g. EAGAIN=EWOULDBLOCK on all platforms, EDEADLOCK=EDEADLK on most),
> I've moved the more popular one (in terms of 'git grep -w Efoo | wc)
> to the bottom so that one takes precedence.
Looks reasonable to me.
Is there any existing kernel code which presently uses this? Can we
get some conversions done to demonstrate and hopefully test the
feature?
Powered by blists - more mailing lists