[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5240A1DB.6020906@att.net>
Date: Mon, 23 Sep 2013 15:17:31 -0500
From: Daniel Santos <danielfsantos@....net>
To: David Howells <dhowells@...hat.com>
CC: Joe Perches <joe@...ches.com>,
Daniel Santos <daniel.santos@...ox.com>,
linux-kbuild <linux-kbuild@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Michal Marek <mmarek@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Thomas Gleixner <tglx@...utronix.de>,
Michael Kerrisk <mtk.manpages@...il.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
George Spelvin <linux@...izon.com>
Subject: Re: [PATCH 5/5] lib: Add error string support to printks
On 09/20/2013 08:07 AM, David Howells wrote:
> I suspect he doesn't really need to implement a "strerror()" function but
> should rather build it straight into printk()/vsprintf().
>
> David
Indeed we don't necessarily *need* a strerror() function per-se, but it
is an addition to the libc support in the kernel. I'll leave it up to
the community to decide rather or not it should be separate or
integrated into vsprintf.c. Also, there is no POSIX or GNU libc
extension (that I am aware of) to print an error name -- a real shame
imho, so the name strerror_name() is pretty much artificial. Is there a
significant overhead in having these functions exported?
Personally, I would think that the only reason to have interest in an
error name or message in the kernel is to output via printk, but I like
to allow room for the conditions that I may not have thought of.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists