lkml.org 
[lkml]   [2019]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1 1/2] vsprintf: introduce %dE for error constants
On Sun 2019-08-25 11:14:42, Uwe Kleine-König  wrote:
> Hello Andrew,
>
> On Sat, Aug 24, 2019 at 04:58:29PM -0700, Andrew Morton wrote:
> > (cc printk maintainers).
>
> Ah, I wasn't aware there is something like them. Thanks
>
> > On Sun, 25 Aug 2019 01:37:23 +0200 Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> >
> > > pr_info("probing failed (%dE)\n", ret);
> > >
> > > expands to
> > >
> > > probing failed (EIO)
> > >
> > > if ret holds -EIO (or EIO). This introduces an array of error codes. If
> > > the error code is missing, %dE falls back to %d and so prints the plain
> > > number.

What was the motivation for this patch, please?

Did it look like a good idea?
Did anyone got tired by searching for the error codes many
times a day?
Did the idea came from a developer, support, or user, please?

> add/remove: 2/0 grow/shrink: 4/2 up/down: 1488/-8 (1480)
> Function old new delta
> errorcodes - 1200 +1200
> errstr - 200 +200
> vsnprintf 884 960 +76
> set_precision 148 152 +4
> resource_string 1380 1384 +4
> flags_string 400 404 +4
> num_to_str 288 284 -4
> format_decode 1024 1020 -4
> Total: Before=21686, After=23166, chg +6.82%
>
> But that doesn't seem to include the size increase for all the added
> strings which seems to be around another 1300 bytes.

This non-trivial increase of the size and the table still
includes only part of the error codes.

The array is long, created by cpu&paste, the index of each code
is not obvious.

There are ideas to make the code even more tricky to reduce
the size, keep it fast.

Both, %dE modifier and the output format (ECODE) is non-standard.

Upper letters gain a lot of attention. But the error code is
only helper information. Also many error codes are misleading because
they are used either wrongly or there was no better available.

There is no proof that this approach would be widely acceptable for
subsystem maintainers. Some might not like mass and "blind" code
changes. Some might not like the output at all.

I am not persuaded that all this is worth it. Also I do not like
the non-standard solution.

Best Regards,
Petr

\
 
 \ /
  Last update: 2019-08-26 14:06    [W:0.114 / U:3.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site